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Abstract 


Future civilian rescue and military operations will depend on a complex system of communi- 
cating devices that can operate in highly dynamic environments. In order to present a consistent 
view of a complex world, these devices will need to maintain data objects with atomic (lineariz- 
able) read/write semantics. 

Lynch and Shvartsman have recently developed a reconfigurable atomic read/write memory 
algorithm for such environments [12, 13] This algorithm, called RAMBO, guarantees atomic- 
ity for arbitrary patterns of asynchrony, message loss, and node crashes. RAMBO installs new 
configurations lazily, transferring data from old configurations to new configurations using a 
background information transfer task. That task handles configurations sequentially, transfer- 
ring information from each configuration to the next. 

This paper presents a new algorithm, RAMBo II, that implements a radically different ap- 
proach to installing new configurations: instead of operating sequentially, the new algorithm 
reconfigures “aggressively”, transferring information from old configurations in parallel. This 
improvement substantially reduces the time necessary to remove obsolete configurations, which 
in turn substantially increases the fault-tolerance. This paper presents a formal specification of 
the new algorithm, a correctness proof, and a conditional analysis of its performance. Prelimi- 
nary empirical studies performed using LAN implementations of RAMBO and the new algorithm 
illustrate the advantages of the new algorithm. 
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1 Introduction 


Future large scale civilian rescue and military deployment operations will involve large numbers of 
communication and computing devices operating in highly dynamic network substrates. Successful 
coordination and marshaling of human resources and equipment involves collecting information 
about a complex real-world situation using sensors and input devices, gathering the information in 
survivable repositories, and providing appropriate and coherent information to the stakeholders. 

Data objects with atomic (linearizable) read/write semantics commonly occur in such settings. 
Replication of objects is a prerequisite for fault-tolerance and availability, and with replication 
comes the need to maintain consistency. Additionally, in dynamic settings where participants may 
join and leave the environment, may fail, and where the physical objects migrate, one needs to be 
able to effectively move the corresponding data objects from one set of data owners to another. 

Lynch and Shvartsman developed a reconfigurable atomic read/write memory algorithm for dy- 
namic networks [12, 13]. The algorithm, called RAMBO, guarantees atomicity for arbitrary patterns 
of asynchrony, message loss, and node crashes. Conditional performance analysis of the algorithm 
shows that when the environment timing stabilizes, when failures are within specific parameters, 
and when the reconfigurations are not frequent and not bursty, then read and write operations 
have small latency bounded in terms of the maximum message delay and the periodic gossip inter- 
val. However when the reconfigurations are frequent or bursty, this algorithm may perform poorly 
because of the inherently sequential processing of the new configurations once they become deter- 
mined by the algorithm. In particular, the number of configurations maintained by the algorithm 
may grow without bound, leading to the unbounded number of messages necessary in processing 
the read and write operations. Such situations may arise due to failures or asynchrony, yet these 
are not the only reasons. Even in synchronous failure-free environments the world dynamics may 
require that frequent reconfigurations are performed to keep track of the rapidly moving physical 
objects or rapidly changing set of stakeholders. 

This paper presents a new algorithm, RAMBO II, integrated with RAMBO, that implements 
a radically different approach to installing new configurations: instead of operating sequentially, 
the new algorithm reconfigures “aggressively”, transferring information from old configurations in 
parallel. This improvement substantially reduces the time necessary to process new configurations 
and to remove obsolete configurations from the system, which in turn substantially increases fault- 
tolerance. This is due to the fact that once a configuration is removed, the system no longer depends 
on it, and as soon as the configuration is removed, it is allowed to fail. The process executing the 
new algorithm achieves a linear speed-up in the number of old configurations known to the process. 
For example, our conditional performance analysis shows that if a process knows about a sequence 
of h configurations, then the it can eliminates all but one of these configurations in time O(1), as 
compared to the original RAMBO, where this takes O(h) time. Additionally, the new algorithm 
reduces the number of messages necessary to process these configurations 

This paper presents a formal specification of the new algorithm, a correctness proof, and a 
conditional analysis of its performance. Preliminary empirical studies performed using LAN imple- 
mentations of RAMBO and the new algorithm illustrate the advantages of the new algorithm. 


Background. Starting with the work of Gifford [6] and Thomas [18], intersecting collections of 
sets found use in several algorithms providing consistent data in distributed settings. Depend- 
ing on the algorithm and its setting, such collections of sets, called quorums when any two have 
non-empty intersection, represent either sets of processors or their knowledge. Upfal and Wigder- 
son [19] use majority sets of readers and writers to emulate shared memory in a distributed setting. 


Vitanyi and Awerbuch [20] implement multi-writer/multi-reader registers using matrices of single- 
writer/single-reader registers where the rows and the columns are written and respectively read 
by specific processors. Attiya, Bar-Noy and Dolev [1] use majorities of processors to implement 
single-writer/multi-reader objects in message passing systems. Such algorithms assume a static 
processor universe and rely on static static quorum systems. 

In long-lived systems where processors may dynamically join and leave the system, it is impor- 
tant to reconfigure a quorum system to adapt it to the new set of processors [8, 4, 7, 17]. Prior 
approaches required that the new quorum system include processors from the old quorum system. 
This is stated as a static constraint on the quorum system that needs to be satisfied during or even 
before the reconfiguration. In our work on reconfigurable atomic memory [15, 5, 12] we replace 
the space-domain requirement on successive quorum system intersections with the time-domain re- 
quirement that some quorums from the old and the new system are involved in the reconfiguration 
algorithm. Such systems are more dynamic because they allow for more choices of new quorum 
systems and do not require that successive configurations intersect. 


Reconfiguration in Highly Dynamic Settings. Lynch and Shvartsman’s earlier algorithms [15 
5] allowed a single distinguished process to act as the quorum system reconfigurer. The advantage 
of the single-reconfigurer approach is its relative simplicity and efficiency: any process maintains at 
most two configurations, the current configuration and the proposed new configuration. The dis- 
advantage of the single reconfigurer is that it is a single point of failure — no further reconfiguration 
is possible if the reconfigurer fails. 

The RAMBO algorithm [12, 13] removed the requirement of having a single reconfigurer, thus 
enabling any process within its own current configuration to begin reconfiguration to a new quorum 
system supplied by the environment. The algorithm implements atomic shared memory suitable for 
use in highly dynamic settings, and it guarantees atomicity in any asynchronous execution and in 
the presence of arbitrary process and network failures. However the multiple-reconfigurer approach 
introduces the problem of maintaining multiple configurations and removing old configurations 
from the system. RAMBO implements a sequential “garbage-collection” algorithm where processes 
remove obsolete configurations one-at-a-time. Configuration removal requires that information is 
propagated from the earliest known configuration to its successor. Since arbitrarily many new 
configurations may be introduced this leads to an unbounded number of old configurations that 
need to be sequentially removed. 

The environment may introduce new configurations for several reasons: (i) due to failures 
and network instability that endanger installed configurations, (71) due to the mobility of the 
physical objects represented by the abstract memory objects and the mobility of the processes 
maintaining the object replicas, and (717) due to the need to rebalance loads on processes within 
installed configurations. Frequent or bursty reconfiguration can substantially increase the number 
of installed configurations and, since a process performing a read or a write operation potentially 
needs to contact quorums in all configurations known to it, this leads to the corresponding increase 
in the number of messages needed to perform the operation. 


The New Algorithm. The primary contribution of this paper is a new algorithm for reconfig- 
urable atomic memory, based on the original RAMBO, that implements an aggressive configuration- 
replacement protocol where any locally-known contiguous sequence of configurations is replaced by 
the last configuration in the sequence. The removal of the old configurations is done in parallel, 
while preserving all other properties of the original RAMBO. Specifically, we maintain a loose cou- 
pling between the reconfiguration algorithms and the original RAMBO algorithms implementing the 
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read and write operations. 

In order to achieve availability in the presence of failures, the objects are replicated at several 
network locations. In order to maintain memory consistency in the presence of small and transient 
changes, the algorithm uses configurations, each of which consists of a set of members plus sets of 
read-quorums and write-quorums. In order to accommodate larger and more permanent changes, 
the algorithm supports reconfiguration, by which the set of members and the sets of quorums are 
modified. Such changes do not cause violations of atomicity. Any quorum configuration may be 
installed at any time—no intersection requirement is imposed on the sets of members or on the 
quorums of distinct configurations. 

The algorithm is composed of a main algorithm, which handles reading, writing, and replace- 
ment of old configurations with a successor configuration, and a global configuration announcement 
service, Recon, which provides the main algorithm with a consistent sequence of configurations. 
Several configurations may be known to the algorithm at one time, and read and write operations 
can use them all without any harm. 

The main algorithm performs read and write operations requested by clients using a two-phase 
strategy, where the first phase gathers information from read-quorums of active configurations 
and the second phase propagates information to write-quorums of active configurations. This 
communication is carried out using background gossiping, which allows the algorithm to maintain 
only a small amount of protocol state information. Each phase is terminated by a fixed point 
condition that involves a quorum from each active configuration. Different read and write operations 
may execute concurrently: the restricted semantics of reads and writes permit the effects of this 
concurrency to be sorted out afterward. 

The main algorithm provides a new configuration-replacement algorithm that removes old 
configurations while ensuring that their use is no longer necessary for maintaining consistency. 
Configuration-replacement also uses a two-phase strategy, where the first phase communicates in 
parallel with all old configurations being removed and the second phase communicates with a new 
configuration. A configuration-replacement operation ensures that both a read-quorum and a write- 
quorum of each old configuration learn about the new configuration, and that the latest value from 
all old configurations is conveyed to a write-quorum of the new configuration. The strength of 
the new algorithm is that it proceeds aggressively in parallel. An arbitrary number of old config- 
urations can be replaced in constant time (assuming bounded message latency and non-failure of 
active configurations). 

The configuration announcement service is implemented by a distributed algorithm that uses 
distributed consensus to agree on the successive configurations. Any member of the latest config- 
uration c may propose a new configuration at any time; different proposals are reconciled by an 
execution of consensus among the members of c. Consensus is, in turn, implemented using a version 
of the Paxos algorithm [9], as described formally in [3]. Although such consensus executions may 
be slow—in fact, in some situations, they may not even terminate—they do not cause any delays 
for read and write operations. 

All services and algorithms, and their interactions, are specified using I/O automata. We 
show correctness (atomicity) of the algorithm for arbitrary patterns of asynchrony and failures. 
On the other hand, we analyze performance conditionally, based on certain failure and timing 
assumptions. For example, assuming that gossip and configuration-replacement occur periodically, 
and that quorums of active configurations do not fail, we show that read and write operations 
complete within time 8d, where d is the maximum message latency. Note that the original RAMBO 
algorithm also had to assume also that garbage-collection is able to keep up—this assumption is 
not necessary in the new algorithm due to the new configuration replacement algorithm. For the 


configuration replacement algorithm we show that any number of configurations can be replaced 
by their successor in constant time. 

At the same time, all the performance results of the original RAMBO algorithm still hold; in 
instances where the network is reliable and timely throughout the execution, the bounds described 
in the previous RAMBO papers [12, 13] still hold. 

Implementations of RAMBO and RaAmso II on a LAN are currently being completed [16]. 
Preliminary empirical studies performed using this implementation illustrate the advantages of the 
new algorithm over the previous one. 


Document Structure. In Section 2 we describe the original RAMBO algorithm of Lynch and 
Shvartsman, and then in Section 3 present and discuss the formal specification of RAMBO II. In 
Section 4 we present some notation, and restate some basic lemmas, only slightly modified from 
RAMBO. In Section 5 we prove that the new algorithm guarantees atomic consistency. In Section 6 
we present the reconfiguration service. In Section 7 we analyze the performance of RAMBO IIT, and 
discuss in detail the areas in which this algorithm improves over the original RAMBO algorithm. In 
Section 8 we discuss the preliminary performance results. Finally, in Section 9 we summarize the 
results, and areas for future research. 


2 The Original Rambo Algorithm 


In this section, we present the original RAMBO algorithm, on which the new algorithm RAMBO II 
is based. RAMBO is an algorithm designed to support read/write operations on an atomic shared 
memory. 

In order to achieve fault tolerance and availability, RAMBO replicates data at several network 
locations. The algorithm uses configurations to maintain consistency in the presence of small and 
transient changes. Each configuration consists of a set of members plus sets of read-quorums and 
write-quorums. The quorum intersection property requires that every read-quorum intersect every 
write-quorum. Read and write operations are implemented as a two-phase protocol, in which each 
phase accesses a set of read or write quorums. 

RAMBO supports reconfiguration, which modifies the set of members and the sets of quorums, 
thereby accommodating larger and more permanent changes without violating atomicity. In this 
way, failed nodes can be removed from active quorums, and newly joined nodes can be integrated 
into the system. Any quorum configuration may be installed at any time — no intersection require- 
ment is imposed on the sets of members or on the quorums of distinct configurations. 

The RAMBO algorithm consists of three kinds of automata: 


e Joiner automata, which handle join requests, 


e Recon automata, which handle reconfiguration requests, and generate a totally ordered se- 
quence of configurations, and 


e Reader-Writer automata, which handle read and write requests, manage garbage collection, 
and send and receive gossip messages. 


In this paper, we discuss only the Reader-Writer automaton. The Joiner automaton is quite 
simple; it sends a join message when node 7 joins, and sends a join-ack message in response to join 
messages. The Recon automaton depends on a consensus service, implemented using Paxos [9], to 
agree on a total ordering of configurations. However, we assume that this total ordering exists, and 


therefore need not discuss this automaton any further. For more details of these two automata, see 
the original RAMBO paper [12, 13]. 

The complete implementation S is the composition of all the automata described above—the 
Joiner;, Reader-Writer;, and Recon; automata for all 7, and all the channels, with all the actions 
that are not external actions of the RAMBO specification hidden. 


Input: Output: 
join(rambo, J)z,:, J a finite subset of J— {i}, cE X,ie 7, join-ack(rambo)s,;,2€ X,iE] 
such that if 7 = (io), then J=@ read-ack(v)z2,i, Uv € Ve, cE X,1ET 
readr,i, CEX,1ET write-ack, ;, 2E X,iE] 
write(v)2,i, UE Ve, TEX, 1ET recon-ack(b)z,:, b € {ok, nok},x € X,ie] 
recon(c,c’)xi, c,¢ €C,i € members(c), cE X, iE] report(c)z,i, cE C,cE Xie T 
fail;, i€ I 


Figure 1: RAMBO(z): External signature 


The external signature for RAMBO appears in Figure 1. The algorithm is specified for a single 
memory location, and extended to implement a complete shared memory. A client uses the join; 
action to join the system. After receiving a join-ack;, the client can issue read; and write; requests, 
which results in read-ack; and write-ack; responses. The client can issue a recon; request to propose 
a new configuration. Finally, the fail; action is used to model node 3 failing. 

The signature and state for the Reader-Writer automata is presented in Figure 2. The code 
for the Reader-Writer automata is presented in Figure 3. All three operations, read, write, and 
garbage-collect, are implemented using gossip messages. Unlike in many other algorithms, there are 
no directed messages specified in this algorithm; at no point does a given node, say 7, decide to send 
a message specifically to node j. Instead, at regular intervals node 7 will non-deterministically send 
all of its public state to other nodes. Progress in an operation occurs when enough information 
has been exchanged. After initiating an operation, the automaton waits until it can be sure that it 
has shared state with enough other nodes (using gossip messages), and then declares the operation 
complete. The phase numbering regime, implemented using pnum1 and pnum2 is used to determine 
when enough communication has completed. 

Every node maintains a tag and a value for the data object. Every new value is assigned a 
unique tag, with ties broken by process-ids. These tags are used to determine an ordering of the 
write operations, and therefore determine the value that a read operation should return. 

Read and write operations require two phases, a query phase and a propagation phase, each 
of which accesses certain quorums of replicas. Assume the operation is initiated at node i. See 
Figure 5 for a summary of the two phases. First, in the query phase, node 7 contacts read quorums 
to determine the most recent available tag and value. Then, in the propagation phase, node i 
contacts write quorums. If the operation is a read operation, the second phase propagates the 
largest tag discovered in the query phase, and its associated value. If the operation is a write 
operation, node 7 chooses a new tag, strictly larger than every tag discovered in the query phase 
and propagates the new tag and the new value to the write quorums. Note that every operation 
accesses both read and write quorums. 

During a phase of an operation, whenever node 7 receives a gossip message from node j, it 
compares the largest phase number j has received from i (by examining pns) to the local phase 
number when the operation began. If 7 initiated the gossip message after receiving a message from 
i sent after the phase began, then i adds j to the acc set. In effect, there has been a round-trip 
message sent from 7 to 7 back to 7. Also, 7 then updates its op.cmap if necessary. 

Garbage collection operations remove old configurations from the system. A garbage collection 


Signature: 


Input: Internal: 
read; query-fix, 
write(v);,v € V prop-fix; 
new-config(c, k);, c € C,k € Nt gc(k)i, KEN 
recv(join);,:, 9 € I — {i} gc-query-fix(k);, k € N 
recv(m);,;, ME M,j ET gc-prop-fix(k);, k € N 
join(rw); gc-ack(k);,k EN 
fail; 

Output: 


join-ack(rw); 
read-ack(v);, v EV 
write-ack; 

send(m)i,;, mE M, jel 


State: 
status € {idle, joining, active, failed}, initially idle op, a record with fields: 
world, a finite subset of I, initially @ type € {read, write} 
value € V, initially vo phase € {idle, query, prop, done}, initially idle 
tag € T, initially (0,70) pnum EN 
cmap € CMap, initially cmap(0) = co, cmap € CMap 
cmap(k) = 1 fork >1 acc, a finite subset of I 
pnum1 EN, initially 0 value € V 
pnum2, a mapping from I to N, initially 
everywhere 0) gc, a record with fields: 
failed, a Boolean, initially false phase € {idle, query, prop}, initially idle 
pnum EN 
acc, a finite subset of I 
cmap € CMap 
inder € N 


Figure 2: Reader-Writer;: Signature and state 


operation involves two configurations: the old configuration being removed and the new config- 
uration being established. See Figure 6 for a summary of the two phases. A garbage collection 
operation requires two phases, a query phase and a propagation phase. The first phase contacts 
a read-quorum and a write-quorum from the old configuration, and the second phase contacts a 
write-quorum from the new configuration. 

Note that, unlike a read or write operation, the first phase of the garbage-collection operation 
must contact two types of quorums: a read-quorum and a write-quorum for the configuration being 
garbage-collected. This ensures that enough nodes are aware of the new configurations, and ensures 
that any ongoing read/write operations will include the new, larger, configuration. 

The cmap is a mapping from integer indices to configurations U{ 1, +}, that initially maps every 
index to L. The cmap tracks which configurations are active, which are not defined, indicated by 
t, and which are removed, indicated by +. The total ordering on configurations determined by 
the Recon automata ensures that all nodes agree on which configuration is stored in each position 
in the array. We define c(k) to be the configuration associated with index k. 

The record op stores information about the current phase of an ongoing read or write operation, 
while gc stores information about an ongoing garbage collection operation. (A node can process 


Output send((W, v, t, em, pns, pnr));,; 
Precondition: 

afailed 

status = active 

j € world 

(W, v,t,cm, pns, pnr) = 

(world, value, tag, cmap, pnum1 , pnum2(j)) 

Effect: 

none 


Input recv((W, v, t,cm, pns, pnr)) j,i 
Effect: 
if sfailed then 
if status # idle then 
status < active 
world < world UW 
if t > tag then (value, tag) < (v,t) 
cmap <— update(cmap, cm) 
pnum2(j) + max(pnum2(j), pns) 
if op.phase € {query, prop} and pur > op.pnum then 
op.cmap « ertend(op.cmap, truncate(cm)) 
if op.cmap € Truncated then 
op.acc + op.acc U {j} 
else 
op.acc + o 
op.cmap + truncate(cmap) 
if gc.phase € {query, prop} and pnr > gc.pnum then 
gc.ace + gc.acc U {7} 


Input new-config(c, k); 
Effect: 
if sfailed then 
if status # idle then 
cmap(k) «+ update(cmap(k),c) 


Input read, 
Effect: 
if sfailed then 
if status # idle then 
pnuml — pnum1 +1 
(op.pnum, op.type, op.phase, op.cmap, op.acc) 
+ (pnum1, read, query, truncate(cmap), 0) 


Input write(v); 
Effect: 
if sfailed then 
if status # idle then 
pnuml «+ pnumi +1 


(op.pnum, op.type, op.phase, op.cmap, op.acc, op.value) 


+ (pnum1,write, query, truncate(cmap),@, v) 


Internal query-fix, 
Precondition: 

afailed 

status = active 

op.type € {read, write} 

op.phase = query 

Vk EN, cE C: op.cmap(k) =c 

=> AR € read-quorums(c) : R C op.acc 

Effect: 

if op.type = read then op.value « value 

else value < op.value 

tag < (tag.seq + 1,12) 

pnuml + pnumi +1 

op.pnum <— pnumi 

op.phase <— prop 

op.cmap < truncate(cmap) 

op.acc + o 


Internal prop-fix, 
Precondition: 

afailed 

status = active 

op.type € {read, write} 

op.phase = prop 

Vk EN,cEC: op.cmap(k) =c 

=> AW € write-quorums(c) : W C op.acc 

Effect: 

op.phase = done 


Output read-ack(v); 
Precondition: 
afailed 
status = active 
op.type = read 
op.phase = done 
v = op.value 
Effect: 
op.phase = idle 


Output write-ack, 
Precondition: 
afailed 
status = active 
op.type = write 
op.phase = done 
Effect: 
op.phase = idle 


Figure 3: Reader-Writer;: Read/write transitions 


Internal gc(k); Internal gc-prop-fix(k); 
Precondition: Precondition: 
afailed afatled 
status = active 
gc.phase = idle 


status = active 
gc.phase = prop 


cmap(k) € C gc.indes = k 
emap(k +1) €C AW € write-quorums(cmap(k +1)):W C gc.ace 
k =0 or cmap(k-—1) =+ Effect: 

Effect: 


cmap(k) H+ + 
pnuml + pnum1 +1 

ge-pnum <— pnumt Internal gc-ack(k); 
gc.phase <— query Precondition: 
gc.acc + 0 afailed 


gc.inder — k status = active 


gc.inder =k 
cmap(k) =+ 
Internal gc-query-fix(k); Effect: 
Precondition: gc.phase = idle 
afailed 


status = active 

gc.phase = query 

gc.inder =k 

cmap(k) #+ 

AR € read-quorums(cmap(k)) : 

AW € write-quorums(cmap(k)) : 
RUW C ge.acc 


Effect: 
pnuml + pnumi +1 
gc.pnum <— pnuml 
gc.phase < prop 
gc.acc + @ 


Figure 4: Reader-Writer;: Rambo Garbage-collection transitions 


read and write operations even when a garbage collection operation is ongoing.) The op.cmap 
subfield records the configuration map for an operation. This consists of the node’s cmap when 
a phase begins, augmented by any new configurations discovered during the phase. A phase can 
complete only when the initiator has exchanged information with quorums from every non-removed 
configuration in op.cmap. The pnum subfield records the phase number when the phase begins, 
allowing the initiator to determine which responses correspond to the current phase. The acc 
subfield records which nodes from which quorums have responded during the current phase. 

In RAMBO, configurations go through three phases: proposal, installation, and upgrade. First, 
a configuration is proposed by a recon event. Next, if the proposal is successful, the Recon service 
achieves consensus on the new configuration, and notifies participants with decide events. When 
every non-failed member of the previous configuration has been notified, the configuration is in- 
stalled. The configuration is upgraded when every configuration with a smaller index has been 
removed at some process in the system. Once a configuration has been upgraded, it is responsible 
for maintaining the data. 


3 Formal Specification of RAMBo II 


In this section we present the new algorithm in detail, and discuss how it differs from the RAMBO 
algorithm. The complete implementation, S, is the composition of all the automata described—the 
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Operation initiated by read; or write(v); 
Phase 1 : 


e Node i communicates with a read-quorum from each configuration in op.cmap in order to determine the 
largest value/tag pair. 


Phase 2 : 


e Node i communicates with a write-quorum from each configuration in in op.cmap to notify it of the 
current largest value/tag pair (or the new value/tag pair, if it is a write operation). 


Figure 5: Summary of two phase read or write operation 


Joiner; and Recon; automata described in RAMBO, the new Reader- Writer; automaton described 
here, for all 2, and all the channels — with all the actions that are not external actions of the RAMBO 
II specification hidden. 

The key problem that prevents rapid stabilization in the original algorithm is the sequential 
nature of the configuration upgrade mechanism: in RAMBO, configurations are upgraded one at 
a time, in order. (Recall that in RAMBO, a configuration is upgraded when every configuration 
with a smaller index has been garbage collected.) Configuration c(k) can be upgraded only if 
configuration c(k — 1) has previously been upgraded. This requirement arises from the need to 
ensure that information is preserved as configurations are changed. As in RAMBO, a configuration 
in RAMBO II is upgraded when every configuration with a smaller index has been removed at some 
process in the system. RAMBO II, however, implements a new reconfiguration protocol that can 
upgrade any configuration, even if configurations with smaller indices have not been upgraded. 
Unlike in RAMBO, then, there may be configurations that are not upgraded until they themselves 
are removed, at the same instant that some configuration with a larger index is upgraded. 

After RAMBO II completes an upgrade operation for some configuration, all configurations 
with smaller indices can be removed. Thus a single upgrade operation in RAMBO II potentially 
has the effect of many garbage collection operations in RAMBO, each of which can only remove 
a single configuration. The name has been changed to emphasize the operation’s active role in 
configuration management: configuration upgrade is an inherent part of preparing a configuration 
to assume responsibility for the data. The code for the new configuration management mechanism 


Operation initiated by gc(k); 
Phase 1 : 


e Node i communicates with a read-quorum from configuration c(k) in order to determine the largest 
value/tag pair. 


e Node i communicates with a write-quorum from configuration c(k) in order to notify it of configuration 
k+1. 


Phase 2 : 


e Node i communicates with a write-quorum from configuration c(k +1) to notify it of the current largest 
value/tag pair. 


Figure 6: Summary of two phase garbage-collection operation 
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Signature: Configuration Management State: 


As in RAMBO, with the following modifications: As in RAMBO, with the following replacing the gc 
Internal: record: 
cfg-upgrade(k);, k € N°° upg, a record with fields: 
cfg-upg-query-fix(k);, k € N°° phase € {idle, query, prop}, initially idle 
cfg-upg-prop-fix(k);, k € N°° pnum EN 
cfg-upgrade-ack(k);, k € N°° cmap € CMap, 
acc, a finite subset of I 
target © N 


Configuration Management Transitions: 


Internal cfg-upgrade(k); Internal cfg-upgrade-ack(k); 
Precondition: Precondition: 
afailed afailed 
status = active status = active 
upg.phase = idle upg.target = k 
(A) cmap(k) € C VEEN €<k: cmap(é)=+ 
cmap(k — 1) € C' Effect: 
(B) VEEN £€<k: cmap(€) AL upg.phase = idle 
Effect: 
pnuml + pnumi1 +1 Output send((W, v, t, cm, pns, pnr))i,; 
(C) upg < (query, pnum1, cmap, O, k) Precondition: 
afailed 
Internal cfg-upg-query-fix(k); status = active 
Precondition: j € world 
afailed (W, v,t, cm, pns, pnr) = 
status = active (world, value, tag, cmap, pnum1, pnum2(j)) 
upg.phase = query Effect: 
upg.target = k none 
(D) VELEN £<k: upg.cmap(é) €C 
=> JR € read-quorums(upg.cmap(é)) : Input recv((W, v,t,cm, pns, pnr)) j,i 
AW € write-quorums(upg.cmap(£)) : Effect: 
(EB) RUW C upg.acc if =failed then 
Effect: if status # idle then 
pnuml — pruml +1 status < active 
(F) upg.pnum — pnuml world <— world UW 
upg.phase < prop if t > tag then (value, tag) < (v,t) 
(G) upg.acc + 0 cmap + update(cmap,cm) 
pnum2(j) < max(pnum2(j), pns) 
Internal cfg-upg-prop-fix(k); if op.phase € {query, prop} and pur > op.pnum then 
Precondition: op.cmap « extend(op.cmap, truncate(cm)) 
afailed if op.cmap € Truncated then 
status = active op.acc + op.acc U {j} 
upg. phase = prop else 
upg.target = k op.acc + o 
(H) AW € write-quorums(upg.cmap(k)) : W C upg.acc op.cmap < truncate(cmap) 
Effect: if upg.phase € {query, prop} and pnr > upg.pnum then 
(1) for LEN:£<kdo upg.acc <- upg.acc U {7} 
(J) cmap (£) + + 


Figure 7: Reader-Writer;: Configuration Management transitions 
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appears in Figure 7. All labeled lines in this section refer to the code therein. 

We now describe in more detail the configuration upgrade operation, which is at the heart of 
RAMBO II. A configuration upgrade is a two-phase operation, much like the garbage-collection 
operation in RAMBO. See Figure 8 for a summary of the two phases. An upgrade operation is 
initiated at node i with a cfg-upgrade(k) event. When this happens, cmap(k) must be defined, that 
is, must be a valid configuration € C (line A). Additionally, for every configuration £ < k, cmap(é) 
must be either € C or removed, that is, + (line B). 

We refer to configuration c(k) as the target of the upgrade operation, and we refer to the set 
of configurations to be removed, {c(Z):@< k A upg.cmap(é) € C}, as the removal-set of the 
configuration upgrade operation. The configuration management mechanism guarantees that the 
removal-set consists of configurations with a contiguous set of indices. 

As a result of the cfg-upgrade event, node i initializes its upg state (line C), and begins the 
query phase of the upgrade operation. In particular, node 7 stores its current cmap in upg.cmap, 
which records the configurations that are currently active. Only these configurations (and, in fact, 
only those with index smaller than k) matter during the operation; new configurations are ignored. 

The query phase continues until node 7 receives responses from enough nodes. In particular, 
for every configuration c(@) with index less than k in upg.cmap, there must exist a read-quorum, 
R, of configuration c(£), and a write-quorum, W, of configuration c(/) such that 7 has received a 
response (that is, a recent gossip message) from every node in RU W (lines D-E). 

When the query phase completes, a cfg-upg-query-fix event occurs. When this event occurs, 
node 7 then has the most recent tag and value discovered by operations using configurations with 
index smaller than &. Further, all configurations with indices smaller than k have been notified of 
configuration c(k). Node 7 then reinitializes upg to begin the propagation phase (lines F—G). 

The propagation phase continues until node 7 receives responses from a write-quorum in con- 
figuration c(k). In particular, there must exist a write-quorum, W, of configuration c(k), such that 
i has received a response from every node in W (line H). 

When the propagation phase completes, a cfg-upg-prop-fix event occurs, which verifies the ter- 
mination condition. At this point node 7 has ensured that configuration c(k) has received the most 
recent value known to 7, which, as a result of the query phase, is itself a recent value. At this point, 
the configurations with index < k are no longer needed, and node 7 removes these configurations 
from its local cmap, setting cmap(@) = + for all @ < k (line I-J). Gossip messages may eventually 
notify other processes that these configurations have been removed. 

Finally, a cfg-upgrade-ack(k) event notifies the client that configuration c(k) has been success- 
fully upgraded. 

Notice that the algorithm allows a nondeterministic choice of which configuration to upgrade 
— and therefore which configurations to remove. Therefore it is possible to restrict the algorithm 
so that it removes only the smallest configuration, upgrading the configurations one at a time. In 
this case the algorithm progresses exactly as the original RAMBO algorithm. Therefore it is clearly 
possible, by restricting the nondeterminism appropriately, to implement RAMBO II in such a way 
as to guarantee equivalent performance as RAMBO. However we will show that by allowing greater 
flexibility we can achieve equivalent safety results and improved performance. 

The new algorithm introduces several difficulties not present in RAMBO. Consider, for example, 
a nice property guaranteed by the sequential garbage collection algorithm in RAMBO: every con- 
figuration is upgraded before it is removed. In RAMBO II, on the other hand, some configurations 


‘In the conference version of the paper, this line was omitted. The removal of this line has no detrimental effect 
on the algorithm, since the operation then completes in zero time. However for clarity sake it is included. 
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Operation initiated by cfg-upgrade(k);: 
Phase 1 : 
e Node i communicates with a read-quorum from each configuration being removed in order to determine 
the largest value/tag pair. 
e Node i communicates with a write-quorum from each configuration being removed to notify it of the 
new, active configuration. 


Phase 2 : 


e Node i communicates with a write-quorum from the target configuration being upgraded, to notify it of 
the current largest value/tag pair. 


Figure 8: Summary of two phase configuration upgrade operation 


never receive up to date information; a configuration may be upgraded at the same instant it is 
removed. 

As a result of this fact, a number of plausible improvements fail. Assume that during an 
ongoing upgrade operation for configuration c(k) initiated by node 7, node i receives a message 
indicating that configuration c(k’) has been removed, for some k’ < k. In RAMBO II, node i sets 
cmap(k’) = +, but does not change upg.cmap. Consider the following incorrect modification to the 
configuration management mechanism. When node i receives such a message, it sets upg.cmap(k’) 
to +. Since the configuration has been removed, it seems plausible that the configuration upgrade 
operation can safely ignore it, thus completing more quickly. It turns out, however, that this 
improvement results in a race condition that can lead to data loss. The configuration upgrade 
operation that removes configuration c(k’) might occur concurrently with the operation at node 
i upgrading configuration c(k). This concurrency might result in data being propagated from 
configuration c(k’) to a configuration c(k”) : k! < k” < k that has already been processed by the 
upgrade operation at node 7. The data thus propagated might then be lost. 


4 Notation and Basic Lemmas 


This section is, to a large extent, a restatement of notation and results from the original RAMBO 
paper [13]. Some of the notation in the proofs has been slightly modified to account for the new 
configuration management mechanism, and some of the proofs have therefore been updated, but 
the results are essentially unchanged. Much of this section is taken directly from [13]. 


4.1 Good Executions 


Throughout the rest of this paper, we will talk about “good” executions of the algorithm. In this 
section, we present a set of environment assumptions that define a “good” execution. In general, 
the assumptions we will present require well-formed requests: clients follow the protocol to join and 
to initiate reconfigurations; clients initiate only one operation at a time; clients wait for appropriate 
acknowledgments before proceeding. 

We consider executions of S (recall that S is the entire system combining Reader- Writer, Recon 
and Joiner automata) whose traces satisfy certain assumptions about the environment. We call 
these good executions. In particular, an “invariant” is a statement that is true of all states that 
are reachable in good executions of S. The environment assumptions are simple “well-formedness” 
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conditions: 
e Weil-formedness for Reader- Writer: 


— For every x and 2: 


* No join(rambo, *);, ready j, write(*), 3, or recon(*,*),,; event is preceded by a fail; 
event. 


* 


At most one join(rambo, *),,;, event occurs. 


* 


Any read,;, write(*);, or recon(*,*),; event is preceded by a join-ack(rambo), ; 
event. 


* 


Any read,;, write(*), 4, or recon(*, *)z,; event is preceded by an -ack event for any 
preceding event of any of these kinds. 


— For every x and c, at most one recon(*,c)z,. event occurs. (This says that configuration 
identifiers that are proposed in recon events are unique. It does not say that the mem- 
bership and/or quorum sets are unique—just the identifiers. The same membership 
and quorum sets may be associated with different configuration identifiers.) Unique- 
ness of configuration identifiers is achievable using local process identifiers and sequence 
numbers. 

— For every c, c’, x, and i, if a recon(c,c’)z 4 event occurs, then it is preceded by: 

* A report(c),; event, and 
* A join-ack(rambo),,; event for every 7 € members(c). 


e Well-formedness for Recon:? 


— For every 2: 

+ No join(recon); or recon(x*, *); event is preceded by a fail; event. 

*« At most one join(recon); event occurs. 

*« Any recon(x,*); event is preceded by a join-ack(recon); event. 

*« Any recon(x, *); event is preceded by an -ack for any preceding recon(x, *); event. 
— For every c, at most one recon(*,c), event occurs. 
— For every c, c’, x, and i, if a recon(c,c’); event occurs, then it is preceded by: 

* A report(c); event, and 

* A join-ack(recon); for every 7 € members(c’). 


4.2 Notational conventions 


In this section, we introduce some definitions and notational conventions, and we add certain history 
variables to the global state of the system S. 
Definitions: 


e update, a binary function on C, defined by update(c, c’!) = max(c,c’) if c and c’ are compa- 
rable (in the augmented partial ordering of Cx), update(c, c) = c otherwise. 


e extend, a binary function on C1, defined by eztend(c,c!) = c ifc = L and c € C, and 
extend(c,c') = c otherwise. 


?The following properties appear in Section 6, but we repeat them here for completeness. 
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e CMap, the set of configuration maps, defined as the set of mappings from N to C4. The 
update and extend operators are extended element-wise to binary operations on C'Map. 


e truncate, a unary function on CMap, defined by truncate(cm)(k) = L if there exists @ < k 
such that cm(£) = L, truncate(cm)(k) = cm(k) otherwise. This truncates configuration map 
cm by removing all the configuration identifiers that follow a L. 


e Truncated, the subset of CMap such that cm € Truncated if and only if truncate(cm) = cm. 


e Usable, the subset of CMap such that cm € Usable iff the pattern occurring in cm consists 
of a prefix of finitely many +s, followed by an element of C’, followed by an infinite sequence 
of elements of C'U {L} in which all but finitely many elements are _L. 


An operation is a pair (n,i) consisting of a natural number n and an index i € I. Here, i is the 
index of the process running the operation, and n is the value of pnum1; just after the read, write, 
or cfg-upgrade event of the operation occurs. 

We introduce the following history variables: 


e in-transit, a set of messages, initially Q). 
A message is added to the set when it is sent by any Reader- Writer; to any Reader- Writer ;. 
No message is ever removed from this set. 


e For every k €N: 


1. c(k) € C, initially undefined. 
This is set when the first new-config(c, k); occurs, for some c and 7. It is set to the c that 
appears as the first argument of this action. 


e For every operation 7: 


1. tag(m) € T, initially undefined. 
This is set to the value of tag at the process running 7, at the point right after 1’s query-fix 
or cfg-upg-query-fix event occurs. If 7 is a read or configuration upgrade operation, this 
is the highest tag that it encounters during the query phase. If 7 is a write operation, 
this is the new tag that is selected for performing the write. 


e For every read or write operation 7: 
1. query-cmap(m), a CMap, initially undefined. 


This is set in the query-fix step of 7, to the value of op.cmap in the pre-state. 


2. R(z,k), for k € N, a subset of J, initially undefined. 
This is set in the query-fix step of 7, for each k such that query-cmap(m)(k) € C. It is 
set to an arbitrary R € read-quorums(c(k)) such that R C op.acc in the pre-state. 


3. prop-cmap(m), a CMap, initially undefined. 
This is set in the prop-fix step of 7, to the value of op.cmap in the pre-state. 


4. W(x,k), for k € N, a subset of J, initially undefined. 
This is set in the prop-fix step of 7, for each k such that prop-cmap(m)(k) € C. It is set 
to an arbitrary W € write-quorums(c(k)) such that W C op.acc in the pre-state. 


e For every configuration upgrade operation y for k: 
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1. removal-set(y), a subset of N, initially undefined. 
This is set in the cfg-upgrade step of y, to the set {@: £< k, cmap(¢) #4 +}. 

2. R(y, 2), for 2€ N, a subset of J, initially undefined. 
This is set in the cfg-upg-query-fix step of y, for each @ € removal-set(y), to an arbitrary 
R € read-quorums(c(£)) such that R C upg.acc in the pre-state. 

3. W1i(7,4), for 2 € N, a subset of J, initially undefined. 
This is set in the cfg-upg-query-fix step of y, for each @ € removal-set(y), to an arbitrary 
W € write-quorums(c(£)) such that W C upg.acc in the pre-state. 

4. W2(y), a subset of J, initially undefined. 
This is set in the cfg-upg-prop-fix step of y, to an arbitrary W € write-quorums(c(k)) 
such that W C upg.acc in the pre-state. 


In any good execution a, we define the following events (more precisely, we are giving additional 
names to some existing events): 


1. For every read or write operation 7: 


(a) query-phase-start(z7) , initially undefined. 
This is defined in the query-fix step of 7, to be the unique earlier event at which the 
collection of query results was started and not subsequently restarted. This is either a 
read, write, or recv event. 


S 


prop-phase-start(7), initially undefined. 

This is defined in the prop-fix step of 72, to be the unique earlier event at which the 
collection of propagation results was started and not subsequently restarted. This is 
either a query-fix or recv event. 


4.3 Configuration map invariants 


In this section, we give invariants describing the kinds of configuration maps that may appear in 
various places in the state of S. We begin with a lemma saying that various operations yield or 
preserve the “usable” property: 


Lemma 4.1 — 1. If cm,cm’ € Usable then update(cm, cm’) € Usable. 


2. Ifcm € Usable, k € N, c € C, and cm’ is identical to cm except that cm'(k) = update(cm(k),c), 
then cm! € Usable. 


3. If cm,cm' € Usable then extend(cm, cm’) € Usable. 


4. If cm € Usable then truncate(cm) € Usable. 


Proof. Part 1 is shown using a case analysis based on which of cm and cm’ has a longer prefix 
of +s. Part 2 uses a case analysis based on where k is with respect to the prefix of +s. Part 3 and 
Part 4 are also straightforward. 


The next invariant (recall from Section 4.1 that this means a property of all states that arise 
in good executions of S) describes some properties of cmap, that hold while Reader- Writer; is 
conducting a configuration upgrade operation: 


Invariant 4.2 If upg.phase; 4 idle and upg.target; =k, then: 
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1. V6: £<k => cmap(é); € CU {+}. 


2. If ky = minfl:£<k and upg.cmap(£) 4 } then ky =0 or cmap(k, — 1); = +. 


Proof. By the precondition of cfg-upgrade(k); and monotonicity of all the changes to cmap,. 


We next proceed to describe the patterns of C, L, and + values that may occur in configuration 
maps in various places in the system state. 


Invariant 4.3 Let cm be a CMap that appears as one of the following: 
1. The cm component of some message in in-transit. 

cmap, for anyi € I. 

op.cmap; for some i € I for which op.phase F idle. 


query-cmap(m) or prop-cmap(x) for any operation 7. 


Sir RS FS, 8S 


upg.cmap; for somei€ I for which upg.phase # idle. 


Then cm € Usable. 


In the following proof and elsewhere, we use dot notation to indicate components of a state, for 
example, s.cmap; indicates the value of cmap; in state s. 


Proof. By induction on the length of a finite good execution. 


Base: Part 1 holds because initially, in-transit is empty. Part 2 holds because initially, for ev- 
ery 1, cmap(0); = co and cmap(k); = 1; the resulting CMap is in Usable. Part 3 and Part 5 
hold vacuously, because in the initial state, all op.phase and upg.phase values are idle. Part 4 also 
holds vacuously, because in the initial state, all query-cmap and prop-cmap variables are undefined. 


Inductive step: Let s and s’ be the states before and after the new event, respectively. We consider 
Parts 1-5 one by one. 

For Part 1, the interesting case is a send; event that puts a message containing cm in in-transit. 
The precondition on the send action implies that cm is set to s.cmap;. The inductive hypothesis, 
Part 2, implies that s.cmap; € Usable, which suffices. 

For Part 2, fix 7. The interesting cases are those that may change cmap;, namely, new-config;, recv; 
for a gossip (non-join) message, and cfg-upg-prop-fix;. The latter case is the only one modified from 
the original RAMBO algorithm. 


1. new-config(c, *);. 
By inductive hypothesis, s.cmap; € Usable. The only change this can make is changing a L 
to c. Then Lemma 4.1, Part 2, implies that s’.cmap,; € Usable. 


2. recv((*, *, Cm, *, *));. 
By inductive hypothesis, cm € Usable and s.cmap; € Usable. The step sets s’.cmap, to 
update(s.cmap,;,cm). Lemma 4.1, Part 1, then implies that s’.cmap; € Usable. 
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3. cfg-upg-prop-fix(k);. 


This sets cmap(@); to + for all 2 < k. By the definition of this step, s’.cmap(@); = + for 
bk, 
If s.cmap(k — 1); = +, then the operation has no effect, and s’.cmap; = s.cmap,; € Usable. 


Assume, then, that s.cmap(k — 1); € CU{1L}. This implies, by the inductive hypothesis 
showing s.cmap, € Usable, that s.cmap(é); € CU{L} for all 2>k—-— 1. By Invariant 4.2, we 
know that s.cmap(k); € CU {+}, and therefore s.cmap(k); € C. Therefore s’.cmap(k); € C 
and s’.cmap(£); € CU{1L} for all ¢ > k, since the cfg-upg-prop-fix does not change entries 
in the cmap larger than k — 1. Further, there are only finitely many entries in s.cmap; that 
are in C (by the inductive hypothesis), and so there are still only finitely many entries in 
s'.cmap;. Therefore, s’.cmap; € Usable. 


For Part 3, the interesting actions to consider are those that modify op.cmap, namely, read;, write;, 
recv;, and query-fix;. 


1. read;, write;, or query-fix;. 
By inductive hypothesis, s.cmap; € Usable. The new step sets s’.op.cmap, to truncate(s.cmap,); 
since s.cmap; € Usable, Lemma 4.1, Part 4, implies that this is also usable. 


2: reev (e, &, cms, &) gs 
This step may alter op.cmap; only if s.op.phase € { query, prop}, and then in only two ways: 
by setting it either to extend(s.op.cmap,, truncate(cm)) or to truncate (update(s.cmap;,cm)). 
The inductive hypothesis implies that s.op.cmap;, cmap;, and cm are all in Usable. Lemma 4.1 
implies that truncate, extend, and update all preserve usability. Therefore, s’.op.cmap; € 
Usable. 


For Part 4, the actions to consider are query-fix; and prop-fix;. 


1. query-fix;. 
This sets s’.query-cmap, to the value of s.op.cmap;. Since by inductive hypothesis the latter 
is usable, so is s’.query-cmap,. 


2. prop-fix;. 
This sets s’.prop-cmap,; to the value of s.op.cmap,;. Since by inductive hypothesis, the latter 
is usable, so is s’.prop-cmap,. 


For Part 5, the actions to consider are cfg-upgrade(k); and cfg-upg-query-fix(k);. These set s’.upg.cmap, 
to the value of s.cmap,;. Since by the inductive hypothesis the latter is usable, so is s’.upg.cmap,. 


We now strengthen Invariant 4.3 to say more about the form of the CMaps that are used for 
read and write operations: 


Invariant 4.4 Let cm be a CMap that appears as op.cmap; for some1€ I for which op.phase; # 
idle, or as query-cmap(m) or prop-cmap(m) for any operation 7. Then: 


1. cm © Truncated. 


2. em consists of finitely many + entries followed by finitely many C' entries followed by an 
infinite number of L entries. 
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Proof. We prove that the desired properties hold for a cm that is op.cmap;. The same properties 
for query-cmap; and prop-cmap; follow by the way they are defined, from op.cmap;. 

To prove Part 1 we proceed by induction. In the initial state, op.phase; = idle, which makes 
the claim vacuously true. For the inductive step we consider all actions that alter op.cmap,: 


1. read;, write;, or query-fiz;. 
These set op.cmap,; to truncate(cmap;), which is necessarily in Truncated. 


2. recv;. 
This first sets op.cmap,; to a preliminary value and then tests if the result is in Truncated. 
If it is, we are done. If not, then this step resets op.cmap,; to truncate(cmap,), which is in 
Truncated. 


To see Part 2, note that cm € Usable by Invariant 4.3. The fact that cm € Truncated then 
follows from the definition of Usable and Part 1. 


4.4 Phase guarantees 


In this section, we present results saying what is achieved by the individual operation phases. We 
give four lemmas, describing the messages that must be sent and received and the information flow 
that must occur during the two phases of configuration-upgrades and during the two phases of read 
and write operations. 

Note that these lemmas treat the case where 7 = 7 uniformly with the case where 7 #7. This 
is because, in the Reader-Writer algorithm, communication from a location to itself is treated 
uniformly with communication between two different locations. We first consider the query phase 
of a configuration-upgrade: 


Lemma 4.5 Suppose that a cfg-upg-query-fix(k); event for configuration upgrade operation y occurs 
in a and k’ € removal-set(y). Suppose j € R(y,k') UW,(4, k’). 
Then there exist messages m from i to 7 and m! from j to i such that: 


1. m is sent after the cfg-upgrade(k); event of y. 

2. m' is sent after 7 receives m. 

3. m! is received before the cfg-upg-query-fix(k); event of y. 

4. In any state after j receives m, cmap(£); A L for all 0<k. 
d 


. tag(y) >t, where t is the value of tag; in any state before 7 sends message m’. 


Proof. The phase number discipline implies the existence of the claimed messages m and m’. 

For Part 4, the precondition of cfg-upgrade(k) implies that, when the cfg-upgrade(k); event of 
y occurs, cmap(£); A 1 for all 2< k. Therefore, j sets cmap(é); # L for all € < k when it receives 
m. Monotonicity of cmap, ensures that this property persists forever. 

For Part 5, let ¢ be the value of tag, in any state before 7 sends message m’. Let t’ be the value 
of tag; in the state just before 7 sends m'. Then t < t’, by monotonicity. The tag component of 
m! is equal to t’, by the code for send. Since 7 receives this message before the cfg-upg-query-fix(k), 
it follows that tag(y) is set by 7 to a value > t. 


Next, we consider the propagation phase of a configuration upgrade: 
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Lemma 4.6 Suppose that a cfg-upg-prop-fix(k); event for a configuration upgrade operation y oc- 
curs ina. Suppose that 7 € W2(y). 
Then there exist messages m from i to 7 and m! from j to i such that: 


1. m is sent after the cfg-upg-query-fix(k); event of y. 
2. m' is sent after 7 receives m. 
3. m' is received before the cfg-upg-prop-fix(k); event of y. 


4. In any state after j receives m, tag; > tag(y). 


Proof. The phase number discipline implies the existence of the claimed messages m and m’. 
For Part 4, when 7 receives m, it sets tag; to be > tag(y). Monotonicity of tag; ensures that 
this property persists in later states. 


Next, we consider the query phase of read and write operations: 


Lemma 4.7 Suppose that a query-fix; event for a read or write operation m occurs in a. Let 
k,k’ EN. Suppose query-cmap(m)(k) € C and j € R(z,k). 
Then there exist messages m from i to 7 and m’ from j toi such that: 


1. m is sent after the query-phase-start(7) event. 
2. m' is sent after j receives m. 
3. m’ is received before the query-fix event of 7. 


4. If t is the value of tag; in any state before 7 sends m’, then: 


(a) tag(m) >t. 
(b) If x is a write operation then tag(x) > t. 


5. If cmap(); A 1 for all &< k’ in any state before j sends m', then query-cmap(m)(£) € C' for 
some > k’. 


Proof. The phase number discipline implies the existence of the claimed messages m and m’. 

For Part 4, the tag component of message m’ is > t, so 7 receives a tag that is > ¢ during the 
query phase of 7. Therefore, tag(z) > t. Also, if 7 is a write, the effects of the query-fix imply that 
tag(m) > t. 

Finally, we show Part 5. In the cm component of message m’, cm(€) # L for all £ < k’. 
Therefore, truncate(cm)(£) = cm(£) for all  < k’, so truncate(cm)(£) # for all £< k’. 

Let cm’ be the configuration map extend(op.cmap,, truncate(cm)) computed by i during the 
effects of the recv event for m’. Since 7 does not reset op.acc to in this step, by definition of the 
query-phase-start event, it follows that cm’ € Truncated, and cm’ is the value of op.cmap; just after 
the recv step. 

Fix 2,0 << k’. We claim that cm’(¢£) 4 L. We consider cases: 


1. op.cmap(£); #4 L just before the recv step. 
Then the definition of extend implies that cm’(£) # L, as needed. 
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2. op.cmap(é); = L just before the recv step and truncate(cm)(£) € C. 
Then the definition of extend implies that cm’(@) € C, which implies that cm’(¢) # L, as 
needed. 

3. op.cmap(é); = L just before the recv step and truncate(cm)(£) ¢ C. 


Since truncate(cm)(@) # L, it follows that truncate(cm)(£) = +. Since truncate(cm)(@) = + 
and truncate(cm) € Usable, it follows that, for some @’ > £, truncate(cm)(’) € C. 


By the case assumption, op.cmap(@); = L just before the recv step. Since, by Invariant 4.4, 
op.cmap, € Truncated, it follows that op.cmap(¢’); = L before the recv step. 


Then by definition of extend, we have that cm’(¢) = L while cm’(é’) € C. This implies that 


cm! € Truncated, which contradicts the fact, already shown, that cm’ ¢ Truncated, So this 
case cannot arise. 


Since this argument holds for all 0, 0 < @ < k’, it follows that cm'(@) # L for all 2 < k’. Since 
cm'(€) # 1 for all 2 < k’, Invariant 4.3 implies that cm’ € Usable, which implies by definition of 
Usable that cm’(£) € C for some £ > k’. That is, op.cmap,(@) € C for some ¢ > k’ immediately 
after the recv step. This implies that query-cmap(m)(@) € C for some £ > k’, as needed. 


And finally, we consider the propagation phase of read and write operations: 


Lemma 4.8 Suppose that a prop-fix; event for a read or write operation m occurs in a. Suppose 
prop-cmap(n)(k) € C and j © W(r,k). 
Then there exist messages m from i to 7 and m! from j to i such that: 


1. m is sent after the prop-phase-start(m) event. 
. m' is sent after 7 receives m. 
. m' is received before the prop-fix event of rm. 


. In any state after j receives m, tag; > tag(m). 
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. If cmap(£); A 1 for all £< k’ in any state before j sends m', then prop-cmap(n)(£) € C for 
some £> ki’. 


Proof. The phase number discipline implies the existence of the claimed messages m and m’. 
For Part 4, let m.tag be the tag field of message m. Since m is sent after the prop-phase-start 
event, which is not earlier than the query-fix, it must be that m.tag > tag(). Therefore, by the 
effects of the recv, just after 7 receives m, tag; > m.tag > tag(z). Then monotonicity of tag; 
implies that tag; > tag(m) in any state after j receives m. 
For Part 5, the proof is analogous to the proof of Part 5 of Lemma 4.7. In fact, it is identical 
except for the final conclusion, which now says that prop-cmap(m)(£) € C for some £ > k’. 


5 Atomic Consistency 


This section contains the proof of atomic consistency. The proof is carried out in several stages. 
First in Section 5.1 we present some lemmas about the new configuration management mechanism, 
describing the relationship between configuration upgrade operations. Section 5.2 describes the 
relationship between read/write operations and configuration upgrade operations. Section 5.3 then 
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considers two read or write operations, and culminates in Lemma 5.11, which says that tags are 
monotonic with respect to non-concurrent read or write operations. Finally, Section 5.4 uses the 
tags to define a partial order on operations and verifies the four properties required for atomicity. 


5.1 Behavior of configuration upgrade 


This section presents the key new technical lemmas on which the proof of atomicity is based. Specif- 
ically, we present lemmas describing information flow between configuration upgrade operations. 
These lemmas assert the existence of a sequence of configuration upgrade operations on which we 
can make certain necessary guarantees. In particular, the key property is that the tags are mono- 
tonically increasing with respect to the specific sequence of upgrade operations, guaranteeing that 
value/tag information is propagated to newer configurations. 

The first lemma shows that if all configuration upgrade operations remove two particular con- 
figurations together, then those two configuration are always in the same state in all cmaps. 


Lemma 5.1 Suppose thatk > 0, anda is an execution in which no cfg-upg-prop-fix(k) event occurs 
in a. Suppose that cm is a CMap that appears as one of the following in any state in a: 


1. The cm component of some message in in-transit. 
2. cmap; for anyi€ I. 


If cm(k — 1) = + then cm(k) = +. 


Proof. Fix some a and k > 0 such that no cfg-upg-prop-fix(k) event occurs in a. We pro- 
ceed by induction on the length of a finite prefix of a: for every action in a, if before the action 
cm(k — 1) =+ = > cm(k) = +, then the same implication holds after the action. 


Base: For Part 1, the conclusion follows vacuously because initially in-transit is empty. For Part 
2, the conclusion again follows vacuously because initially cmap,(@) # + for all 7 and 2. 


Inductive step: Let s and s’ be the states before and after the new event, respectively. We consider 
Parts 1 and 2 separately. 

For Part 1, the interesting case is a send; event that puts a message containing cm in in-transit. 
The precondition on the send action implies that cm is set to s.cmap;. The inductive hypothesis, 
Part 2, implies that if s.cmap(k — 1) = +, then s.cmap(k) = +. Therefore in state s’, the same 
holds for em, which has been added to in-transit. 

For Part 2, fix 7. The interesting cases are those that may change cmap,;, namely, new-config;, recv; 


for a gossip message, and cfg-upg-prop-fix;. 


1. new-config(c, *);. 


If s'.cmap(k — 1); = +, then s.cmap(k — 1); = +, since installing a new configuration does 
not set any entry to +. Then by the inductive hypothesis s.cmap(k); = +, which implies 
that s’.cmap(k); = +4, since this action cannot modify an entry that is already +. 


2. recv((*,*, Cm, *, *));. 
First, if cm(0) # +, then the message does not cause any entry in s.cmap to be set to +, 
and as in Case 1 the desired property still holds. Also, if s.cmap(0) # +, then for all Z, 
s’.cmap(£) = + if and only if cm(¢) = +. By the inductive hypothesis cm(k —1) =+ => 
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cm(k) = +, so the desired conclusion follows. For the rest of this case, we will assume that 
cm(0) = + and s.cmap(0) = +. 


By Invariant 4.3, cm € Usable. Therefore we can define kmsg-maz such that cm(@) = + for 
all £< kmsg-maz and cm(¢) # + for all > kmsg-maz- Similarly, we can define kmaz such that 
s.cmap(l); = + for all 2 < kmax and s.cmap(@); # + for all 2 > kmaz. Define ki,,, in the 
same way for the poststate, s’. 


There are two cases. First, assume kinax > kmsg-max. Then ki naz = Kmax, by the monotonicity 


of CMap. By our inductive hypothesis s.cmap(k — 1) = + = > s.cmap(k) = +; it follows, 
then, that if k-—1< kmaz then k < kmaz. Therefore if k —1< kj,,,, then k < ki... Finally, 
then, if s’.cmap(k — 1) = +, then s’.cmap(k) = +. 

Assume, then, that kmsg-maz > kmax- Then after the update operation, ki jg, = Kmsg-maz- 
By our inductive hypothesis, cm(k —1) = + = > cm(k) = +; it follows, then, that if 
k-1< kmsg-maz, then k < kmsg-mar- Therefore if k-—1< k,,,,, then k < kj,,,. Finally, then, 
s'.cmap(k — 1) = + implies that s’.cmap(k) = +. 

3. cfg-upg-prop-fix(k’);. 

By assumption, k # k’. If k < k’, then this operation sets both s’.cmap(k — 1); = + and 
s'.cmap(k); = +. If k > k’, then this operation has no effect on cmap(k); or cmap(k — 1);, 


and the desired property still holds. 


The following corollary says that if a cfg-upgrade(k&) event for an upgrade operation y occurs in 
an execution, then there is some previous configuration upgrade operation 7’ (that completes before 
the upgrade event) where the target of 7’ is the configuration with the smallest index removed by 
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Corollary 5.2 Let be a configuration upgrade operation, initiated by a cfg-upgrade(k); event in a, 
and let ky = min{removal-set(y)}. That is, k, is the smallest element such that upg-cmap(y)(k1) € 
C. Assume k; > 0. Then a cfg-upg-prop-fix(k1); event for some configuration upgrade operation 7! 
occurs in a for some j such that the cfg-upg-prop-fix; event of y' precedes the cfg-upgrade(k); event 
in a. 


Proof. By the definition of k,, we know that in the state just after the cfg-upgrade event, 
upg.cmap(k, — 1); = + and upg.cmap(k1); # +. Since upg.cmap; is set by the cfg-upgrade event 
to cmap; in the state just prior to the cfg-upgrade event, we know that cmap(ki — 1); = + and 
cmap(k1); # + in the state just prior to the cfg-upgrade event. Lemma 5.1, then, implies that some 
cfg-upgrade-prop-fix(k,) event for some operation 7 occurs in a preceding the cfg-upgrade event. 


The next lemma says that for a given configuration upgrade operation 7, there exists a sequence 
of preceding upgrade operations satisfying certain properties. The lemma begins by assuming 
that some configuration with index k is removed by the specified upgrade operation. For every 
configuration with an index smaller than k, we choose a single upgrade operation — that removes 
that configuration — to add to the sequence. Therefore the constructed sequence may well contain 
the same configuration upgrade operation multiple times, if the operation has removed multiple 
configurations. If two elements in the sequence are distinct upgrade operations, then the earlier 
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operation in the sequence completes before the later operation in the sequence is initiated. Also, the 
target of an upgrade operation in the sequence is removed by the next distinct upgrade operation in 
the sequence. As a result of these properties, the configuration upgrade process obeys a sequential 
discipline. 


Lemma 5.3 If acfg-upgrade,; event for upgrade operation y occurs in a such that k € removal-set(y), 
then there exists a sequence (possibly containing repeated elements) of configuration upgrade oper- 
ations Yo, V1;---; Vk with the following properties: 


1.V¥5:0<8s<k, s € removal-set(ys), 


2V8s:0< 85 < k, if ys # Ys41, then the cfg-upg-prop-fix event of ys occurs in a and 
the cfg-upgrade event of Ys41 occurs in a, and the cfg-upg-prop-fix event of y; precedes the 
cfg-upgrade event of Y¥s41, and 


3.V8s:0<8<hk, ifys #7541, then target(ys) € removal-set(ys41). 


Proof. We construct the sequence in reverse order, first defining yz, and then at each step defining 
the preceding element. We prove the lemma by backward induction on ¢, for = k down to £=0, 
maintaining the following three properties at each step of the induction: 


1'.Vs:h<s<k, 8 © removal-set(ys), 


2.V 8s: <8 <k, if ys F 7541, then the cfg-upg-prop-fix event of 7, occurs in a and the 
cfg-upgrade event of 734; occurs in a, and the cfg-upg-prop-fix event of , precedes the 
cfg-upgrade event of y;41, and 


BS. s:h<s<hk, if ys #541, then target(ys) € removal-set (7541). 


To begin the induction, we first examine the base case, where ¢ = k. Define y, = y. Property 1’ 
holds by assumption, and Property 2’ and Property 3’ are vacuously true. 

For the inductive step, we assume that ye has been defined and that properties 1’-3’ hold. 

If 2 = 0, then yo has been defined, and we are done. Otherwise, we need to define yp_;. If 
£—1€ removal-set(ye), then let y~_, = ye, and all the properties still hold. 

Otherwise, 0—1 ¢ removal-set (ye) and £ € removal-set (ye), which implies that = min{ removal-set(y¢)} 
because each configuration upgrade operates on a consecutive sequence of configurations. Then by 
Corollary 5.2, there occurs in @ a configuration upgrade operation, that we label ye_1, with the 
following properties: (i) the cfg-upg-prop-fix event of y_; precedes the cfg-upgrade event of yy, and 
(ii) target(ye_-1) = min{k’ : k’ € removal-set(y)}. 

Recall that 2 = min{removal-set(y)}. Therefore, by Property (ii) of y_1, target(ye_1) = 4. 

Since removal-set(y_1) 4 9, this implies that — 1 € removal-set(ye_1), proving Property 1’. 
Property 2’ follows from Property (i) of y¢_1. Property 3’ follows from Property (ii) of ye_1. 


The sequential nature of configuration upgrade has a nice consequence for propagation of tags: 
for any sequence of upgrade operations like that in Lemma 5.3, tag(y,) is nondecreasing in s. 


Lemma 5.4 Let y,..., 7, be a sequence of configuration upgrade operations such that: 


1.V5:0<8s<k, s € removal-set(ys), 


25 


2V8s:0< 85 < k, if ys # Ys41, then the cfg-upg-prop-fix event of ys occurs in a and 
the cfg-upgrade event of ys41 occurs in a, and the cfg-upg-prop-fix event of y; precedes the 
cfg-upgrade event of Y¥s41, and 


38.V8s:0<8<hk, ifys #7541, then target(ys) € removal-set(ys41). 
Then 8:0<8s<k, tag(ys) < tag(¥s41)- 


Proof. If ys; = ¥s41, then it is trivially true that tag(ys) < tag(7s11). Therefore assume that y, 4 
Ys+1; this implies that the cfg-upg-prop-fix event of y,; precedes the cfg-upgrade event of y,41. Let ke 
be the largest element in removal-set(ys). We know by assumption that ko +1 € removal-set (7541). 
Therefore, W2(y;), a write-quorum of configuration c(k2 + 1), has at least one element in common 
with R(¥s541,k2 + 1); label this node 7. By Lemma 4.6, and the monotonicity of tag,;, after the 
cfg-upg-prop-fix event of y; we know that tag; > tag(ys). Then by Lemma 4.5 tag(ys41) = tag;. 
Therefore tag(ys) < tag(¥s41)- 


Corollary 5.5 Let y,..., 7% be a sequence of configuration upgrade operations such that: 
1.V¥8:0<8s<k, s € removal-set(ys), 


2V58s:0< 8 < k, if ys # Ys41, then the cfg-upg-prop-fix event of ys occurs in a and 
the cfg-upgrade event of Ys41 occurs in a, and the cfg-upg-prop-fix event of y; precedes the 
cfg-upgrade event of 7541, and 


3.V8s:0<8<hk, ifys #7541, then target(ys) € removal-set (7541). 
ThenV s,s':0<s<s' <k, tag(ys) < tag(7s') 


Proof. This follows immediately from Lemma 5.4 by induction. 


5.2 Behavior of a read or a write following a configuration upgrade 


Now we describe the relationship between an upgrade operation and a following read or write op- 
eration. These three lemmas relate the removal-set of a preceding configuration upgrade operation 
with the query-cmap of a later read or write operation. 

The first lemma shows that if, for some read or write operation, k is the smallest index such 
that query-cmap(k) € C, then some configuration upgrade operation with target k precedes the 
read or write operation. 


Lemma 5.6 Let a be a read or write operation whose query-fix event occurs in a. Let k be the 
smallest element such that query-cmap(m)(k) € C. Assume k > 0. Then there must exist a 
configuration upgrade operation y such that k = target(y), and the cfg-upg-prop-fix event of 7 
precedes the query-phase-start(7) event. 


Proof. This follows from Lemma 5.1. Let s be the state just before the query-phase-start(z)) 
event. By definition, query-cmap(m) = s.cmap;. Since s.cmap(k — 1); = = and s.cmap(k); # + 
there must exist such a configuration upgrade operation for k by the contrapositive of Lemma 5.1. 


Second, if some upgrade removing k does complete before the query-phase-start event of a read 
or write operation, then some configuration with index > k+1 must be included in the query-cmap 
of a later read or write operation. 
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Lemma 5.7 Let y be a configuration upgrade operation such that k € removal-set(y). Let m be a 
read or write operation whose query-fix event occurs in a. Suppose that the cfg-upg-prop-fix event 
of y precedes the query-phase-start(m) event in a. 
Then query-cmap(m)(£) € C for some £>k +1. 


Proof. Suppose for the sake of contradiction that query-cmap(m)(£) ¢ C for all 2>k+1. Fix 
k’ = max({@! : query-cmap(m)(é’) € C}). Then k’ < k. 

Let yo,---; 7% be the sequence of upgrade operations whose existence is asserted by Lemma 5.3, 
where 7, = y. Then, by this construction, k’ € removal-set(yz-), and the cfg-upg-prop-fix event of 
yz: does not come after the cfg-upg-prop-fix event of y in a. By assumption, the cfg-upg-prop-fix 
event of y precedes the query-phase-start(7) event in a. Therefore the cfg-upg-prop-fix event of yz’ 
precedes the query-phase-start(7) event in a. 

Then, since k’ € removal-set (yz), write-quorum W} (yz, k’) is defined. Since query-cmap(k’) € 
C), the read-quorum R(z,k’) is defined. Choose 7 € Wy(yp,k’) A R(x, k’). Assume that ky = 
target(y,'). Notice that k’ < kj. Then Lemma 4.5 and monotonicity of cmap imply that, in the 
state just prior to the cfg-upg-query-fix event of yz, cmap(é); A L for all 2 < k;. Then Lemma 4.7 
implies that query-cmap(m)(£) € C for some ¢ > kj. But this contradicts the choice of k’. 


The next lemma describes propagation of tag information from a configuration upgrade opera- 
tion to a following read or write operation. For this lemma, we assume that query-cmap(k) € C, 
where & is the target of the upgrade operation, 


Lemma 5.8 Let y be a configuration upgrade operation. Assume that k = target(y). Let m be a 
read or write operation whose query-fix event occurs in a. Suppose that the cfg-upg-prop-fix event of 
precedes the query-phase-start(7) event in execution a. Suppose also that query-cmap(m)(k) € C. 
Then: 


1. tag(y) < tag(z). 


2. If w is a write operation then tag(y) < tag(z). 


Proof. The propagation phase of 7 accesses write-quorum W2(y) of c(k), whereas the query 
phase of 7 accesses read-quorum R(z,k). Since both are quorums of configuration c(k), they have 
a nonempty intersection; choose 7 € W2(7) N R(z, k). 

Lemma 4.6 implies that, in any state after the cfg-upg-prop-fix event for y, tag; > tag(y). Since 
the cfg-upg-prop-fix event of 7 precedes the query-phase-start(7) event, we have that t > tag(7y), 
where ¢ is defined to be the value of tag, just before the query-phase-start(7) event. Then Lemma 4.7 
implies that tag(a) > t, and if 7 is a write operation, then tag(7) > t. Combining the inequalities 
yields both conclusions of the lemma. 


5.3 Behavior of sequential reads and writes 


Read or write operations that originate at different locations may proceed concurrently. However, 
in the special case where they execute sequentially, we can prove some relationships between their 
query-cmaps, prop-cmaps, and tags. The first lemma says that, when two read or write operations 
execute sequentially, the smallest configuration index used in the propagation phase of the first 
operation is less than or equal to the largest index used in the query phase of the second. In other 
words, we cannot have a situation in which the second operation’s query phase executes using only 
configurations with indices that are strictly less than any used in the first operation’s propagation 
phase. 
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Lemma 5.9 Assume 7 and m2 are two read or write operations, such that: 
1. The prop-fix event of 7, occurs in a. 
2. The query-fix event of m2 occurs in a. 
3. The prop-fix event of 7, precedes the query-phase-start(72) event. 

Then min({é : prop-cmap(m1)(£) € C}) < max({@ : query-cmap(m2)(l) € C}). 


Proof. Suppose for the sake of contradiction that min({@: prop-cmap(m)(£) € C}) > k, where 
k is defined to be max({@ : query-cmap(m2)(£) € C}). Then in particular, prop-cmap(m)(k) € C. 
The form of prop-cmap (m1), as expressed in Invariant 4.4, implies that prop-cmap(m)(k) = +. 

This implies that some cfg-upg-prop-fix event for some upgrade operation y such that k € 
removal-set(y) occurs prior to the prop-fix of 71, and hence prior to the query-phase-start(72) event. 
Lemma 5.7 then implies that query-cmap(m2)(€) € C for some > +1. But this contradicts the 
choice of k. 


The next lemma describes propagation of tag information, in the case where the propagation 
phase of the first operation and the query phase of the second operation share a configuration. 


Lemma 5.10 Assume 7m, and m2 are two read or write operations, and k € N, such that: 


1. The prop-fix event of 71 occurs in a. 
2. The query-fix event of m2 occurs in a. 
3. The prop-fix event of 7, precedes the query-phase-start(72) event. 


4. prop-cmap(m1)(k) and query-cmap(m2)(k) are both in C. 


Then: 
1. tag(m1) < tag(72). 


2. If mq is a write then tag(m) < tag(m2). 


Proof. The hypotheses imply that prop-cmap(m1)(k) = query-cmap(m2)(k) = c(k). Then W (71, k) 
and R(m2,k) are both defined in a. Since they are both quorums of configuration c(k), they have 
a nonempty intersection; choose 7 € W(m,k) N R(mo,k). 

Lemma 4.8 implies that, in any state after the prop-fix event of 7, tag; > tag(m). Since the 
prop-fix event of 7, precedes the query-phase-start(72) event, we have that t > tag(m), where t¢ is 
defined to be the value of tag; just before the query-phase-start (72) event. Then Lemma 4.7 implies 
that tag(m2) > t, and if 72 is a write operation, then tag(z2) > t. Combining the inequalities yields 
both conclusions. 


The final lemma is similar to the previous one, but it does not assume that the propagation 
phase of the first operation and the query phase of the second operation share a configuration. The 
main focus of the proof is on the situation where all the configuration indices used in the query 
phase of the second operation are greater than those used in the propagation phase of the first 
operation. 
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Lemma 5.11 Assume 7 and m2 are two read or write operations, such that: 
1. The prop-fix of 7, occurs in a. 
2. The query-fix of m2 occurs in a. 
3. The prop-fix event of 7 precedes the query-phase-start(72) event. 
Then: 
1. tag(m) < tag(m2). 


2. If mq is a write then tag(m) < tag(r2). 


Proof. Let 7; and 72 be the indices of the processes that run operations 7, and 7, respectively. 
Let cm, = prop-cmap(m1) and cm2 = query-cmap(m2). If there exists k such that cm (k) € C and 
cma(k) € C, then Lemma 5.10 implies the conclusions of the lemma. So from now on, we assume 
that no such k exists. 

Lemma 5.9 implies that min({@: cm,(£) € C}) < max({@: cma(é) € C}). Invariant 4.4 implies 
that the set of indices used in each phase consists of consecutive integers. Since the intervals have 
no indices in common, it follows that 8; < sz, where s1 is defined to be max({é: cm1(@) € C}) and 
82 is defined to be min({@: cma(é) € C}). 

Lemma 5.6 implies that there exists a configuration upgrade operation that we will call y;,-1 
such that so = target(ys,-1), and the cfg-upg-prop-fix of y;,-1 precedes the query-phase-start (72) 
event. Then by Lemma 5.8, tag(7s,-1) < tag(m2), and if m2 is a write operation then tag(75,-1) < 
tag (m2). 

Next we will demonstrate a chain of configuration upgrade operations with non-decreasing tags. 
Lemma 5.3, in conjunction with the already defined y;,,-1, implies the existence of a sequence of 
configuration upgrade operations yo,...,Ys.—1 such that: 


1.V¥s:0<8<s2—1, s € removal-set(ys), 


2.V8s:0<8 < so-1, ifys F ¥s41, then the cfg-upg-prop-fix event of 7, precedes the cfg-upgrade 
event of 7,41 in a, 


3. V8s:0<8< 89-1, ify, #541, then target(y,) € removal-set (7541). 


As a special case of Property 1, since s; < sg — 1, we know that s; € removal-set(y;,). Then 
Corollary 5.5 implies that tag(ys,) < tag(7s5—-1)- 

It remains to show that the tag of 7 is no greater than the tag of y;,. Therefore we focus now 
on the relationship between operation 7; and configuration upgrade y;,. The propagation phase of 
™1 accesses write-quorum W (71,81) of configuration c(s,), whereas the query phase of y,, accesses 
read-quorum R(ys,, 51) of configuration c(s;). Since W(m,s1) 9 R(ys,,51) # 0, we may fix some 
j € W(m71, 51) ON R(ys,,81). Let message m1 from i; to 7 and message m‘, from j to 7, be as in 
Lemma 4.8 for the propagation phase of ¥z,. 

Let message mz from the process running ys, to 7 and message m/ from j to the process running 
Ys, be the messages whose existence is asserted in Lemma 4.5 for the query phase of ¥z,. 

We claim that j sends m/, its message for 71, before it sends m4, its message for y;,. Suppose 
for the sake of contradiction that 7 sends m4, before it sends m{. Assume that s; = target(ys,. 
Notice that s; > 81, since s; € removal-set(ys,). Lemma 4.5 implies that in any state after j 
receives m2, before 7 sends m5, cmap(k); # 1 for all k < s;. Since j sends m4 before it sends 
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m',, monotonicity of cmap implies that just before 7 sends m{, cmap(k); A 1 for all k < s;. Then 
Lemma 4.8 implies that prop-cmap(m)(£) € C for some @ > s;. But this contradicts the choice of 
$1, since 8; < s;. This implies that j sends m{ before it sends m4. 

Since j sends m‘, before it sends m4, Lemma 4.8 implies that, at the time 7 sends m4, tag(71) 
tag; Then Lemma 4.5 implies that tag(m1) < tag(7s,). From above, we know that tag(7s,) 
tag(Ys,-1), and tag(7¥s,-1) < tag(m2), and if zg is a write operation then tag(7;,-1) < tag(72). 
Combining the various inequalities then yields both conclusions. 


< 
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5.4 Atomicity 


In order to prove that all executions of RAMBO II are atomic, we use four sufficient conditions. A 
memory is said to be atomic provided that the following conditions hold for all good executions: 


e If all the read and write operations that are invoked complete, then the read and write 
operations for object x can be partially ordered by an ordering ~<, so that: 


1. No operation has infinitely many other operations ordered before it. 


2. The partial order is consistent with the external order of invocations and responses, that 
is, there do not exist read or write operations 7, and 72 such that 7; completes before 
m2 starts, yet 72 < 7. 


3. All write operations are totally ordered and every read operation is ordered with respect 
to all the writes. 


4. Every read operation ordered after any writes returns the value of the last write preceding 
it in the partial order; any read operation ordered before all writes returns the initial 
value. 


This definition is sufficient to guarantee atomicity in terms of the other common definition which 
is defined in terms of equivalence to a serial memory. (See, for example, Lemma 13.16 in [11].) 

Let 8 be a trace of S, the system that implements RAMBO II (recall that this includes the 
Reader-Writer, Recon and Joiner automata), and assume that all read and write operations com- 
plete in 8. Consider any particular good execution a of S whose trace is 6. We define a partial 
order < on read and write operations in §, in terms of the operations’ tags in a. Namely, we totally 
order the writes in order of their tags, and we order each read with respect to all the writes as 
follows: a read with tag t is ordered after all writes with tags < t and before all writes with tags 
>t. 


Lemma 5.12 The ordering < is well-defined. 


Proof. The key is to show that no two write operations get assigned the same tag. This is obvi- 
ously true for two writes that are initiated at different locations, because the low-order tiebreaker 
identifiers are different. For two writes at the same location, Lemma 5.11 implies that the tag of 
the second is greater than the tag of the first. This suffices. 


Lemma 5.13 < satisfies the four conditions in the definition of atomicity. 
Proof. We begin with Property 2, which as usual in such proofs, is the most interesting thing to 


show. Suppose for the sake of contradiction that 7, completes before m2 starts, yet m2 < mm. We 
consider two cases: 
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1. m9 is a write operation. 
Since 7, completes before 72 starts, Lemma 5.11 implies that tag(m2) > tag(m,). On the 
other hand, the fact that 72 < 7, implies that tag(72) < tag(m1). This yields a contradiction. 
2. 2 is a read operation. 
Since 7, completes before 72 starts, Lemma 5.11 implies that tag(m2) > tag(m,). On the 


other hand, the fact that 72 < 7, implies that tag(72) < tag(m1). This yields a contradiction. 


Since we have a contradiction in either case, Property 2 must hold. 
Property 1 follows from Property 2. Properties 3 and 4 are straightforward. 


Now we tie everything together for the proof of Theorem 5.14. 


Theorem 5.14 Let 6 be a trace of S, the system that implements RAMBO II. Then 6 satisfies the 
atomicity guarantee. 


Proof. Assume that all read and write operations complete in 6. Let a be a good execution of 
S whose trace is 6. Define the ordering < on the read and write operations in 8 as above, using 
the execution a. Then Lemma 5.13 says that ~ satisfies the four conditions in the definition of 
atomicity. Thus, § satisfies the atomicity condition, as needed. 


6 Reconfiguration Service 


In this section we present the specification and implementation for the reconfiguration specification. 
This section is a restatement of Sections 4 and 7 of the RAMBO technical report, and is taken 
directly from [13]. Our RAMBO implementation for each object x consists of a main Reader- Writer 
algorithm and a reconfiguration service, Recon(x); since we are suppressing mention of x, we write 
this simply as Recon. First, in Section 6.1, we present the specification for the Recon service, as 
an external signature and set of traces. In Section 6.2, we present our implementation of Recon. 


6.1 Reconfiguration Service Specification 


The interface for Recon appears in Figure 9. The client of Recon at location i requests to join 
the reconfiguration service by performing a join(recon); input action. The service acknowledges 
this with a corresponding join-ack; output action. The client requests to reconfigure the object 
using a recon; input, which is acknowledged with a recon-ack; output action. RAMBO reports a new 
configuration to the client using a report; output action. Crashes are modeled using fail actions. 

Recon also produces outputs of the form new-config(c,k);, which announce at location 7 that c 
is the k*” configuration identifier for the object. These outputs are used for communication with 
the portion of the Reader-Writer algorithm running at location 7. Recon announces consistent 
information, only one configuration identifier per index in the configuration identifier sequence. 
It delivers information about each configuration to members of the new configuration and of the 
immediately preceding configuration. 

Now we define the set of traces describing Recon’s safety properties. Again, these are defined in 
terms of environment assumptions and and service guarantees. The environment assumptions are 
simple well-formedness conditions, consistent with the well-formedness assumptions for RAMBO: 


e Weil-formedness: 
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Input: Output: 


join(recon);, i € I join-ack(recon);, 7 € I 
recon(c,c’);, c,c’ € C, 1 € members (c) recon-ack(b);, b € {ok, nok},i € I 
fail;, 7 € I report(c);, cE Cie I 


new-config(c,k)i, cE C, REN, iE T 
Figure 9: Recon: External signature 


— For every 2: 
* No join(recon); or recon(*, *); event is preceded by a fail; event. 
*« At most one join(recon); event occurs. 
*« Any recon(x, *); event is preceded by a join-ack(recon); event. 
*« Any recon(x, *); event is preceded by an -ack for any preceding recon(x, «); event. 


— For every c, at most one recon(*,c), event occurs. 
— For every c, c’, x, and i, if a recon(c, c’); event occurs, then it is preceded by: 


* A report(c); event, and 
* A join-ack(recon); for every 7 € members(c’). 


The safety guarantees provided by the service are as follows: 
e Well-formedness: For every 1: 


— No join-ack(recon);, recon-ack(«);, report(*);, or new-config(*, x); event is preceded by a 
fail; event. 

— Any join-ack(recon); (resp., recon-ack(c);) event has a preceding join(recon),; (resp., recon; ) 
event with no intervening invocation or response action for x and 1. 


e Agreement: If new-config(c,k); and new-config(c’,k); both occur, then c = c’. (No disagree- 
ment arises about what the k’” configuration identifier is, for any k.) 


e Validity: If new-config(c, k); occurs, then it is preceded by a recon(x, c); for some 2’ for which 
a matching recon-ack(nok),; does not occur. (Any configuration identifier that is announced 
was previously requested by someone who did not receive a negative acknowledgment.) 


e No duplication: If new-config(c,k); and new-config(c, k’); both occur, then k = k’. (The 
same configuration identifier cannot be assigned to two different positions in the sequence of 
configuration identifiers.) 


6.2 Reconfiguration Service Implementation 


In this section, we describe a distributed algorithm that implements the Recon service for a par- 
ticular object « (and we suppress mention of 7). This algorithm is considerably simpler than the 
Reader-Writer algorithm. It consists of a Recon; automaton for each location 7, which interacts 
with a collection of global consensus services Cons(k,c), one for each k > 1 and each c € C, and 
with a point-to-point communication service. 

Cons(k,c) accepts inputs from members of configuration c, which it assumes to be the k — 1% 
configuration. These inputs are proposed new configurations. The decision reached by Cons(k,c), 
which must be one of the proposed configurations, is determined to be the k*” configuration. 
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Recon, is activated by the joining protocol. It processes reconfiguration requests using the con- 
sensus services, and records the new configurations that the consensus services determine. Recon; 
also conveys information about new configurations to the members of those configurations, and re- 
leases new configurations for use by Reader-Writer;. It returns acknowledgments and configuration 
reports to its client. 


6.3. Consensus services 


In this section, we specify the behavior we assume for consensus service Cons(k,c), for a fixed k > 1 
and c € C. This behavior can be achieved using the Paxos consensus algorithm [9], as described 
formally in [14]. Fix V to be the set of consensus values. (In the implementation of the Recon 
service, V will be instantiated as C.) The external signature of Cons(k,c) is given in Figure 10. 


Input: Output: 
init(v)k,c,4, v € Vy t © members (c) decide(v)x,c,i, v € V, t € members (c) 
fail;, 7 € members(c) 


Figure 10: Cons(k,c): External signature 


We describe the safety properties of Cons(k,c) in terms of properties of a trace 6 of actions in 
the external signature. Namely, we define the client safety assumptions: 


e Well-formedness: For any i € members(c): 


— No init(*)4,¢,4 event is preceded by a fail(i) event. 


— At most one init(*),,¢4 event occurs in £. 
And we define the consensus safety guarantees: 
e Well-formedness: For any i € members(c): 


— No decide(*) 4, event is preceded by a fail(i) event. 
— At most one decide(*);,¢; event occurs in (3. 


— If a decide(*), ¢; event occurs in f, then it is preceded by an init(*), 4; event. 
e Agreement: If decide(v) x4 and decide(v’), ¢47 events occur in 6, then v = v’. 
e Validity: If a decide(v)z,c,, event occurs in 8, then it is preceded by an init(v)x,¢,;. 


We assume that the Cons(k,c) service is implemented using the Paxos algorithm [9], as de- 
scribed formally in [14]. This satisfies the safety guarantees described above, based on the safety 
assumptions: 


Theorem 6.1 If 3 is a trace of Paros that satisfies the safety assumptions of Cons(k,c), then 6 
also satisfies the (well-formedness, agreement, and validity) safety guarantees of Cons(k,c). 


The Pazos algorithm also satisfies the following latency result: 
Theorem 6.2 Consider a timed execution a of the Pazos algorithm and a prefiz a! of a. Suppose 


that: 
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1. The underlying system “behaves well” after a’, in the sense that timing is “normal” (what is 
called “regular” in [14])° and no process failures or message losses occur. 


2. For every i that does not fail in a, an init(*); event occurs in a’. 


3. There exist R € read-quorums(c) and W € write-quorums(c) such that for allie RUW, no 
fail; event occurs in a. 


Then for every i that does not fail in a, a decide(x); event occurs, no later than 9d + time after 
the end of a! (e > 0). 


6.4 Recon automata 


A Recon; process is responsible for initiating consensus executions to help determine new con- 
figurations, for telling the local Reader-Writer; process about a newly-determined configuration, 
and for disseminating information about newly-determined configurations to the members of those 
configurations. The signature and state of Recon; appear in Figures 11, and the transitions in 
Figure 12. 


Signature: 
Input: Output: 
join(recon); join-ack(recon); 
recon(c,c’);,c,c’ € C,i © members(c) new-config(c, k);, c € C,k € Nt 
decide(c)x,i,¢ € C,k € Nt init(c,c’)ai, cc’ € Chk E NT, i © members (c) 
recv((config,c,k))j,i, c€ C, kK ENT, recon-ack(b);, b € {ok, nok} 
i € members(c), 7 € I — {i} report(c);, cE C 
recv((init,c,¢c’,k))j;i, ec. EC, kK ENT, send((config,c, k))ij,c€C, k ENT, 
i,j € members(c), 7 #1 j € members(c) — {i} 
fail; send({init,c,¢’,k))ij,¢,c1 € C,R ENT, 
i,7 € members(c), j i 
State: 
status € {idle, active}, initially idle. cons-data € (N* — (C x C)): initially L everywhere 
rec-cmap € CMap, initially rec-cmap(0) = co rec-status € {idle, active}, initially idle 
and rec-cmap(k) = L for all k £ 0. outcome € {ok, nok, L}, initially L 
did-init C N*, initially 0 reported C C, initially @ 
did-new-config C N*, initially 0 failed, a Boolean, initially false 


Figure 11: Recon;: Signature and state 


Location 7 joins the Recon service when a join(recon) input occurs. Recon; responds with a 
join-ack. 

Recon, includes a state variable rec-cmap, which holds a CMap: rec-cmap(k) = c indicates that 
i knows that c is the Ath configuration identifier. If Recon; has learned that c is the kth configuration 
identifier, it can convey this to its local Reader-Writer; process using a new-config(c, k); output 
action, and it can inform any other Recon; process, 7 € members(c), by sending a (config, c, k) 
message. Recon; learns about new configurations either by receiving a decide input from a Cons 
service, or by receiving a config or init message from another process. 


3In [14], regular timing implies that messages are delivered reliably within time d, that local processing time is 0, 
and that information is “gossiped” at intervals of d. 
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Input join(recon); 
Effect: 
if sfailed then 
if status = idle then 
status < active 


Output join-ack(recon); 
Precondition: 

afailed 

status = active 
Effect: 

none 


Output new-config(c, k); 
Precondition: 
afailed 
status = active 
rec-cmap(k) =c 
k € did-new-config 
Effect: 
did-new-config <— did-new-config U {k} 


Output send((config, c, k))i,; 
Precondition: 
afailed 
status = active 
rec-cmap(k) =c 
Effect: 
none 


Input recv((config, c, k)) 5,1 
Effect: 
if s=failed then 
if status = active then 
rec-cmap(k) < c 


Output report(c); 
Precondition: 

afailed 

status = active 

c & reported 

S = {€: rec-cmap(€) € C} 

c = rec-cmap(max(S)) 
Effect: 

reported « reported U {c} 


Input recon(e, c’); 
Effect: 
if sfailed then 
if status = active then 
rec-status + active 
let S = {€: rec-cmap(é) € C} 
if S AQ and c = rec-cmap(max(S)) 


and cons-data(max(S) +1) = L then 


cons-data(max(S) + 1) € (c,¢’) 
else outcome «+ nok 


Output init(c’) 46,1 
Precondition: 
afailed 
status = active 
cons-data(k) = (c,c’) 
if k > 1 then k € did-new-config 
k € did-init 
Effect: 
did-init — did-init U {k} 


Output send((init, c,c’, k))i,; 
Precondition: 
afailed 
status = active 
cons-data(k) = (c,c’) 
k € did-init 
Effect: 
none 


Input recv((init, c, e’, k))5,i 
Effect: 
if sfailed then 
if status = active then 


if rec-cmap(k — 1) = L then rec-cmap(k — 1) «+ c 


if cons-data(k) = L then cons-data(k) « (c,c’) 


Input decide(c’)1,,i 
Effect: 
if sfailed then 
if status = active then 
rec-cmap(k) < c 
if rec-status = active then 
if cons-data(k) = (c,c’) then outcome «+ ok 
else outcome < nok 


Output recon-ack(b); 
Precondition: 
afailed 
status = active 
rec-status = active 
b = outcome 
Effect: 
rec-status = idle 
outcome <— L 


Input fail, 
Effect: 
failed + true 


Figure 12: Recon;: Transitions. 
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Recon; receives a reconfiguration request from its environment via a recon(c,c’); event. Upon 
receiving such a request, Recon; determines whether (a) 7 is a member of the known configuration 
c with the largest index k — 1 and (b) it has not already prepared data for a consensus for the 
next larger index k. If both (a) and (b) hold, Recon; prepares such data, consisting of the pair 
(c,c’), where c is the k — 1st configuration identifier and c’ is the proposed configuration identifier. 
Otherwise, Recon; responds negatively to the new reconfiguration request. 

Recon; initiates participation in a Cons(k,c) algorithm when its consensus data are prepared. 
After initiating participation in a consensus algorithm, it sends init messages to inform the other 
members of c about its initiation of consensus. The other members use this information to prepare 
to participate in the same consensus algorithm (and also to update their rec-cmap if necessary). 
Thus, there are two ways in which Recon; can initiate participation in consensus: as a result of a 
local recon event, or by receiving an init message from another Recon; process. 

When Recon; receives a decide(c’),; directly from Cons(k,c), it records configuration c’ in 
rec-cmap It also determines if a response to its local client is necessary (if a local reconfiguration 
operation is active), and determines the response based on whether the consensus decision is the 
same as the locally-proposed configuration identifier. 

Each consensus service Cons (k, c) is responsible for conveying consensus decisions to members (c). 
The Recon; components are responsible for telling members(c’) about c’ by sending new-config mes- 
sages. 


Theorem 6.3 The Recon implementation guarantees well-formedness, agreement, and validity. 


7 Conditional Performance Analysis 


In this section we give a conditional latency analysis of the new algorithm, focusing on the im- 
provements realized by the aggressive configuration-upgrade mechanism. We show that the new 
algorithm allows the system to recover rapidly after a period of unreliable network connectivity or 
bursty reconfiguration. In particular, we prove that if configurations do not fail too rapidly, then 
progress is guaranteed. First, in Section 7.1, we present a few general definitions. In Section 7.2 
and 7.3, we define the executions being considered, and the environmental assumptions that these 
executions satisfy. Then in Sections 7.5, 7.6, and 7.7, we prove a series of lemmas that describe 
how long it takes configuration-upgrade operations to complete. Finally, in Section 7.8 we state 
the main stabilization theorem, and prove that operations will complete as long as the execution 
assumptions are met. Throughout this section, we compare the results with those proved in Section 
9 of the RAMBO technical report [13]. 


7.1 Definitions 


In this section, we present a few basic definitions. These definitions do not depend on timing, but 
are needed only for the conditional performance analysis. For these definitions, assume that a@ is 
an execution. 

First we define what it means for a configuration to be installed: configuration c is installed when 
either of the following holds: (i) c = cp or (ii) for some k > 0, for all non-failed i € members(c(k—1)), 
a decide(c),,; event occurs in a. That is, configuration c = c(k) is installed when every non-failed 
member of configuration c(k — 1) performs a decide(c(k)) event. 

Next, we define an event that occurs when a configuration is guaranteed to be ready to 
be upgraded (though an upgrade operation may occur earlier than this event). We define the 
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upgrade-ready(k) event, for k > 0, to be the first event in a after which, Vé < k, the following hold: 
(i) configuration c(¢) is installed, and (ii) Vi € members(c(k — 1)) such that 7 has not failed at the 
time of the event, cmap(¢); A L. 


7.2 Limiting Nondeterminism 


The algorithm, as presented, is highly nondeterministic. Therefore for the purposes of analysis, 
we restrict our attention to a subset of executions in which automata follow certain timing-related 
rules. For the rest of this paper we assume a fixed constant d > 0. We assume that gossip occurs 
at fixed intervals of time d, and also that in times of good behavior messages are delivered within 
time d‘. 


le 


Each node, i € J, performs a send;,; for all 7 € world; every time d as measured by the local 
clock of 7. 


. Each node, i € J, performs a send;,; (an “important” send) whenever any of the following 


occurs: 


Just after a recv(join);; event occurs, if status; = active. 


(Responses for messages) Just after a recv(*, *,*,*,pns,*);, event occurs, if pns > 
pnum2(j); and status; = active. 


Just after a new-config(c, k); event occurs if status; = active and 7 € world;. 


Just after a recv(*,*,*,cm,*,*);; event occurs, if op.phase; # idle and for some k, 

cm(k) # L and cmap(k); = L. 

Just after a read;, write;, or query-fix; event occurs, if 7 € members(c), for some c in the 

range of op.cmap,. 

Just after a cfg-upgrade(k); event occurs for configuration-upgrade 7, if 7 € members(cmap(k’);) 

for any k’ € removal-set(y). 

Just after a cfg-upg-query-fix(k); event occurs for configuration-upgrade ¥, if 7 € members(cmap(k’);) 
where k’ = target (y). 


. Locally controlled actions of any automaton in the system that have no effects, other than 


the important sends described just above, are performed only once. 


. If an action is enabled to occur at node 7, and has not yet been performed (and therefore is 


not restricted by the previous rule), then it occurs immediately, with zero time passing. 


7.3. The Behavior of the Environment 


Much of the analysis in the original RAMBO algorithm makes guarantees about the latency of 
requests when “normal behavior” holds. In Section 9 of [13], Lynch and Shvartsman begin to 
examine how the system behaves in executions that achieve normal behavior after some point. 
Here we adopt a similar model. We first define what it means for an execution to exhibit “normal 
behavior” from some point onward. 


For the rest of the paper, we use the following notation: given some time t € R2°, J(t,e, a) 


represents the set of all nodes j such that join-ack, occurs no later than time ¢—e — 2d in a. (Recall 


“Tt seems, perhaps, that we should not be using d to represent both these quantities; however for consistency with 
the original RAMBO presentation, we continue to use this convention. 
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>e+ 2d 


a Zi 
| | 


Join-ack, i€ J(t) 


Figure 13: Definition of J(t) 


that d has been fixed, above.) In most cases, we will use the notation J(t), when e and a are clear 
from the context. 


7.3.1 Normal Timing Behavior from Some Point Onward 


Let @ be an admissible timed execution, and a’ a finite prefix of a. Arbitrary behavior is allowed 
in a’: messages may be lost or delivered late, clocks may run at arbitrary rates, and in general any 
asynchronous behavior may occur. However we assume that after a’, good behavior resumes. We 
say that a@ is an a’-normal execution if the following assumptions hold: 


1. Initial time: The join-ack;, event occurs at time 0, completing the join protocol for node io, 
the node that created the data object.° 


2. Regular timing: The local clocks of all RAMBO II automata (i.e., Reader- Writer;, Recon;, Joiner ;) 
at all nodes progress at exactly the rate of real time, after a’. 


3. Reliable message delivery: No message sent in @ after a’ is lost. 


4. Message delay bound: If a message is sent at time ¢ in a and it is delivered, then it is delivered 
by time max(t, @time(a’)) + d. 


7.3.2. Configuration—Viability 


Next we will define configuration-viability, which is the key assumption needed to guarantee that 
read and write operations complete. As in all quorum-based algorithms, liveness depends on all 
the nodes in some quorums remaining alive. In RAMBO II, a node can make progress only if it is 
able to communicate with the read and write quorums of all extant configurations. We say that a 
configuration has failed when either: (i) some node in every read-quorum of the configuration has 
failed, or (ii) some node in every write-quorum of the configuration has failed. If a configuration 
fails before a new configuration is installed and the old configuration removed, then the system will 
be effectively crashed: no future read or write request will ever complete. In order to guarantee 
that operations complete, then, it is necessary for the client using the RAMBO II system to initiate 
appropriate reconfigurations to ensure that quorums remain accessible. The configuration viability 
assumption is a complex property, depending on the behavior of the algorithm, the client initiating 
appropriate reconfigurations, and on the patterns of node failure and message loss. 

We define what it means for an execution to be (a’, e, T)-configuration-viable: Let a be an 
admissible timed execution, and let a’ be a finite prefix of a. Let e,7 € R2°. Then a is (a’, e, T)- 
configuration-viable if the following holds: 

For all i,c,k such that cmap(k); = c in some state in a, there exist R € read-quorums(c) and 
W € write-quorums(c) such that at least one of the following holds: 


>This assumption was assumed implicitly in the initial RAMBO papers, and was missing from the list of assumptions. 
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1. No process in RU W fails in a. 


2. There exists a finite prefix Qjnstq1 of a such that for all 2 << k+1, configuration c(£) is installed 
in Qinstalt aNd no process in RU W fails in a by time max(Ltime(a’) + e, time (Qinstail)) + T- 


By assuming that an execution is (a’,e,7 )-configuration-viable, we ensure that the algorithm 
has at least time 7 after a new configuration is installed to clean up obsolete configurations. Also, 
since all configurations are viable until at least time e+ 7 after a’, the algorithm has at least time 
e+7 after the system stabilizes to clean up obsolete configurations. 


7.3.3 Recon-Spacing 


While reconfigurations cannot impede a read/write operation, too frequent reconfigurations can 
slow down a read/write operation by introducing new quorums that must be contacted. In or- 
der to bound the time required for a read/write operation, we need to bound the frequency of 
reconfigurations. 

There are two components to Recon-Spacing. Let a be an a/-normal execution, and e € R2°. 
Then a satisfies: 


1. (a’,e)-recon-spacing-1: if for any recon(c, *); event in a after a’ the preceding report(c); event 
occurs at least time e earlier. 


2. (a’,e)-recon-spacing-2: if for any recon(c, x); event in a after a’ there exists a write-quorum 
W € write-quorums(c) such that for all 7 € W, report(c); precedes the recon(c, *); event in a. 


We say that a satisfies (a’,e)-recon-spacing if it satisfies both (a’,e)-recon-spacing-1 and (a’,e)- 
recon-spacing-2. 

Notice that, instead of assuming the second part of this requirement, we could instead modify 
the recon automaton to enforce this ordering: the automaton could collect gossip messages indi- 
cating which nodes had performed a report(c), and delay or abort the next recon if it preceded an 
appropriate set of report events. We choose to instantiate this as an assumption, rather than as a 
modification to the automaton for two reasons. First, we prefer to retain compatibility with the 
original RAMBO analysis. Second, by stating this as an assumption, it is possible that the client 
using the RAMBO II algorithm might choose to violate the second part of the assumption. As a 
result, those guarantees that depend on this assumption will not hold; however reconfigurations 
may be more performed more frequently. Even if the second part of this assumption is violated, 
safety is still guaranteed: atomicity is maintained, and read and write operations are guaranteed 
to terminate. However, operations might not terminate rapidly in 8d, as in Section 7.8. 


7.3.4 Join-Connectivity 


The hypothesis of join-connectivity is designed to ensure that all non-failing joining processes are 
able to learn about each other. Otherwise, it is possible for the processes to join and fail in such 
a way that the world-views of the nodes are partitioned into multiple components, with different 
nodes aware of different, disconnected pieces of the world. It is also important for the latency 
analysis to bound how long this process takes. If two nodes both complete the join protocol and 
do not fail, then they should learn about each other within a bounded time. For this reason, we 
define the notion of join-connectivity as follows: 
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Let a be an a’/-normal execution, e € R2°. We say that a satisfies (a’,e)-join-connectivity 
provided that: for any time ¢ and nodes i, 7 € J(t,e,q), if neither 7 nor 7 fails until after max(t — 
2d, £time(a’) + e), then by time max(t — 2d, £time(a’) + e), i € world;. 

This indicates, then, that if two nodes both complete joining by some time ¢ after a’, then 
within time e the two nodes are aware of each other. If two nodes both complete joining by some 
time t during a’, then within time e after a’ the two nodes are aware of each other. 

Prior results on joining from [13] suggest that in some cases it can be shown that the current 
simple join protocol in the RAMBO II algorithm provides (a’,d + d[log(|J|)])-join-connectivity. 
However we will not prove - or depend on - this earlier result. Instead we will assume that the 
system provides (a’,e)-join-connectivity for some e, and prove our results in this context. We leave 
it as an open problem to determine the exact value of e; a more complicated and interactive join 
protocol might well provide better results. 


7.3.5 Recon-Readiness 


The next assumption we make is related to the problem of reconfiguration by a node that has 
recently joined. We will assume that every node that is proposed to be a member of a configuration 
has been a member of the RAMBO II system for a reasonable period of time. This allows us to 
conclude that everyone is aware of nodes that are part of active configurations. 

An a’-normal execution a satisfies (a’, e)-recon-readiness if the following property holds: if for 
some node 7 and some configurations c and c’, a recon(c,c’); event occurs in a@ at time t, then: 


e If 7 € members(c’), then 7 performs a join-ack prior to the recon event. 
e If the recon event occurs after a’, and if 7 € members(c’), then 7 € J(t,e,a). 


This prohibits nodes that have just joined the system, but are not yet in anyone’s world view 
from forming new configurations. As long as e is not too large, this seems a reasonable requirement. 


7.3.6 Upgrade-Readiness 


The last assumption we make ensures that a node initiates an upgrade operation only if it has 
joined sufficiently long ago. This ensures that when a node performs an upgrade, it has relatively 
up-to-date information. 

We say that an a’-normal execution a satisfies (a’, e)-upgrade-readiness if the following prop- 
erty holds: if for some i a cfg-upgrade(*); event occurs in @ after a’ at time ¢, then 7 € J(t). 

In particular, we suggest that in an implementation of this algorithm, only members of con- 
figuration c(k) initiate operations to upgrade configuration c(k). In this case, recon-readiness 
guarantees upgrade-readiness. 


7.3.7 Fixed Parameters 


We have already fixed d such that gossip occurs at fixed intervals of time d, and in times of good 
behaviour messages are delivered with time d. We now fix e as well. Additionally, for the rest of 
the paper, we fix a and a’, and assume that a is an a’-normal execution. We therefore sometimes 
suppress these parameters, as they are clear from context. For example, we will use the notation 
J(t) to represent J(t,e,a). When we refer to join-connectivity, we mean (a’, e)-join-connectivity; 
recon-readiness is used to mean (a’,e)-recon-readiness; upgrade-readiness is used to mean (a’, e)- 
upgrade-readiness; T-recon-spacing is used to mean (a’, 7)-recon-spacing; 7-configuration-viability 
is used to mean (a’,e,7)-configuration viability. 
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Figure 14: Lemma 7.2, Case 1 
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a join-ack, recon(x, h) i€ J(t) 


Figure 15: Lemma 7.2, Case 2 


7.4 Basic Lemmas 


In this section, we prove a few basic lemmas that will be useful in the rest of the paper. 
The following two lemmas demonstrate some basic facts about the sets J(x): 


Lemma 7.1 1. Ift <t’, then J(t) C J(t’). 


2. For all t,t’, J(t) C J(max(t,t’)). 


Proof. By definition of J(-). 


The following lemma uses the recon-readiness assumption to say something stronger about the 
joining time of members of a configuration: 


Lemma 7.2 Assume that a is an a’-normal execution satisfying (a’,e)-recon-readiness. If h is a 
configuration proposed at time t’ by a recon(*,h) event, t > t', and t > ftime(a’) + e + 2d, then 
members(h) C J(t). 


Proof. First, assume that t' > €time(a’). Then the result follows immediately by recon-readiness 
and Lemma 7.1. Assume, then, that t’ < £time(a’). By recon-readiness, every member of configura- 
tion h performs a join-ack by £time(a’). Therefore, by definition of J, members(h) C J(£time(a’) + 
e+ 2d). Since t > £time(a’) +e +2d, Lemma 7.1 implies that J(£time(a’) +e + 2d) C J(t). 


The next lemma shows a similar result about upgrade-readiness: 


Lemma 7.3 Assume that a is an a’-normal execution satisfying (a’,e)-upgrade-readiness. If a 
cfg-upgrade(x); event occurs in a at time t, for some node i, then i € J(max(t, Ctime(a’) +e+4 2d)). 


Proof. First, assume that the cfg-upgrade event occurs after a’. Then the lemma follows imme- 
diately by the definition of upgrade-readiness and Lemma 7.1. Assume, then, that the cfg-upgrade 
event occurs in a’. By the precondition of cfg-upgrade, 7 must perform a join-ack prior to the 
cfg-upgrade event; otherwise status; # active when the cfg-upgrade occurs, which contradicts the 
precondition of the cfg-upgrade. Therefore 7 performs a join-ack, at latest at time @time(a’), and 
therefore 1 € J(£time(a’) + e + 2d), and the lemma again follows by Lemma 7.1. 
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7.5 Propagation of Information 


In this section, we introduce the notion of information being in the “mainstream”. Once a sufficient 
set of nodes know a particular fact, then, under appropriate assumptions, this fact will never be 
forgotten by the system as a whole. In particular, we show that this is true about information in 
the cmap: updates to the cmap are propagated. Once every non-failed node in J(t) updates its 
cmap, then at any time in the future, at time t’ > t + 2d, every non-failed node in J(t’) will be 
aware of this update. 

If cm is a CMap and £ is a finite prefix of a with ftime(8) = t > e + 2d, then we say that cm 
is mainstream after 8 provided that the following holds: For every i € J(t) such that fail; does not 
occur in 6, cm < éstate(B).cmap;. 

Further, we define the following notation: given an execution a and a time t € R2°, we define 
B(t, a) to be the finite prefix of a such that @time(G(t, a)) = t and every event that occurs at time t 
occurs in G(t,a). As we have already fixed a, for the rest of this paper we use the simpler notation 
of 3(t). We then say that a CMap cm is mainstream after ¢ if it is mainstream after ((t). 

The first lemma shows a basic property of mainstream cmaps: 


Lemma 7.4 Assume that a is an execution, t is a time, and cm, cm2 are CMaps. If cm < cm2, 
and cm2 is mainstream after t, then cm is mainstream after t. 


Proof. Immediate from the definition of mainstream. 


The following lemma shows that a node’s cmap is monotone: 


Lemma 7.5 Assume that a” is a finite prefix of execution a, and that al” is a prefix of al’. Assume 
that i is a node. Then £state(a’").cmap, < £state(a”).cmap;. 


Proof. In the algorithm, cmap; is only modified by the update function, and the update function 
is monotone; that is, for all CMaps new-cmap, cmap < update(cmap, new-cmap). 


Lemma 7.6 Assume that a is an execution, and t and t' are times, and that t < t'. Assume that 
1 is a node, and cm is a CMap. 


1. If cm < éstate(B(t)).cmap,;, then cm < éstate(G(t’)).cmap;. 


2. Lstate(B(t)).cmap,; < lstate(G(t’)).cmap,. 


Proof. This follows by Lemma 7.5, where a” = (6(t) and a” = G(t'). 


Next, we demonstrate a particular case when a cmap becomes mainstream. 


Lemma 7.7 Let a be an a’-normal execution satisfying (a’,e)-join-connectivity. Let t be a time 
such that t > Ltime(a’') +e. Ifi € J(t+2d), andi does not fail in B(t+d), then lstate(B(t)).cmap; 
is mainstream after t + 2d. 


Proof. Let cm = éstate(G(t)).cmap;. To show that cm is mainstream after t + 2d, we need to 
show that for all 7 € J(t+2d) such that j does not fail in B(t + 2d), cm < éstate(B(t + 2d)).cmap,. 
Fix any such j. By join-connectivity, 7 € world; by time max(t, £time(a’) + e) < t. 

By time ¢ + d, 7 sends a gossip message, msg, to node j such that cm < msg.cmap;. By time 
t+2d, j receives the gossip message and updates cmap, with msg.cmap. By the monotonicity of the 
update function, msg.cmap < update(cmap,;,msg.cmap). Therefore cm < éstate(G(t + 2d)).cmap,, 
as required. 
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Figure 16: Lemma 7.7 
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cm mainstream after t => cm mainstream after t’ + 2d 


Figure 17: Lemma 7.9 


The following lemma shows that if two nodes are both in the set J(t + 2d), then information is 
propagated from one to the other. 


Lemma 7.8 Let a be an a’-normal execution satisfying (a’,e)-join-connectivity. Assume that t 
and t' are times, and t'—2d > t > £time(a’)+e. Assume that i and j are nodes, andi,j € J(t+2d). 
Also, assume that i does not fail in B(t + 2d), and 7 does not fail in B(t'). 

If cm < estate(G(t)).cmap;, then cm < éstate(G(t')).cmap,. 


Proof. By Lemma 7.7, state(G(t)).cmap,; is mainstream after t+ 2d. Notice that j € J(t+ 2d), 
and therefore, by the definition of mainstream, ¢state(G(t)).cmap; < &state(G(t+2d)).cmap;. Since 
t+2d < t’, by Lemma 7.6, state(6(t + 2d)).cmap, < éstate(B(t')).cmap;. Putting the inequalities 
together, cm < éstate(G(t’)).cmap,. 


We now show that once a cmap is in the mainstream, after 2d it will always be in the mainstream. 
First, Lemma 7.9 considers a special case: it considers only times ¢’ after the system has stabilized, 
when a recon(h, h’) event occurs. Second, Lemma 7.10 handles the case where the cmap is in the 
mainstream at a time in a’. Third, Lemma 7.11 proves the existence of a configuration with some 
necessary special properties to prove the main theorem. Finally, Lemmas 7.12 and 7.13 prove the 
general result, as summarized in Lemma 7.14. 

First, we define a successful recon event as follows: a recon(*,c) event is successful if at some 
time afterwards a decide(c),, event occurs for some k and i. 


Lemma 7.9 Let a be an a’-normal execution satisfying: (1) (a’,e)-join-connectivity, (ii) (a’, e)- 
recon-readiness, (iii) (a’, 2d)-recon-spacing-1, and (iv) (a’, e, 2d)-configuration-viability. 
Assume that t and t' are times, and that t > time(a’) +e + 2d and t’' >t. Leth and h’ be two 
configurations, and assume that recon(h,h’), occurs at time t', and that this is a successful recon 
event. 
If cm is mainstream after t, then cm is mainstream after t' + 2d. 
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cm mainstream after t => cm mainstream after a’ + e+ 4d 


Figure 18: Lemma 7.10 


Proof. Fix ¢ and cm such that cm is mainstream after t. We prove the result by induction on 
the number of successful recon events that occur at or after time tf. 

As the base case, consider the first successful recon(h, h’) event that occurs in a at a time t’ > t. 
We need to show that cm is mainstream after t’ + 2d. Therefore fix some j’ € J(t’ + 2d) such that 
fail; does not occur in A(t’ + 2d). We will show that cm < éstate(B(t! + 2d)).cmap jv. 

Choose some node j € members(h) such that 7 does not fail in G(t’ + 2d); that is, 7 does not fail 
until after ¢’ + 2d. Configuration-viability ensures that such a node exists. Notice that 7 € J(t), by 
Lemma 7.2. Since cm is mainstream after t, then cm < ¢state({).cmap,. 

Note that configuration h is proposed prior to time t, since the recon(h, h’) event is the first 
successful recon event at or after time t. Therefore configuration h is also proposed prior to time 
t’. By Lemma 7.1, 7 € J(t’ + 2d). By assumption 7’ € J(t/ + 2d) and does not fail in S(t’ + 2d). 
Therefore, by Lemma 7.8, cm < éstate(G(t' + 2d)).cmap;., as needed. 

Next we show the inductive step. Inductively assume the following: if recon(x, x) is one of the 
first n successful recon events in a that occur at time t' > t, then cm is mainstream after t’. 

Consider the (n + 1)** successful recon(h,h’) event in a that occurs at or after t. Assume 
this event occurs at time t’. We need to show that cm is mainstream after t/ + 2d. Therefore 
fix some j’ € J(t’ + 2d) such that fail, does not occur in ((t/ + 2d). We will show that cm < 
Estate (A(t! + 2d)).emap jv. 

Let p be the n* successful recon(*,h) event, and assume that p occurs at time t;. Note that 
the first argument of the (n+ 1)** successful recon event must be the configuration proposed by the 
n*” successful recon event. 

2d-recon-spacing-1 guarantees that ¢t’ > t, + 2d. The inductive hypothesis shows that cm is 
mainstream after t, + 2d. 

Choose some node j € members(h) such that no fail; occurs in 8(t’+2d). Configuration-viability 
ensures that such a node exists. By recon-readiness and Lemma 7.1, 7 € J(t’+2d). By assumption 
j' € J(t’ + 2d) and 7’ does not fail in B(t’ + 2d). By Lemma 7.8, cm < éstate(B(t! + 2d)).cmap ;, 
as needed. 


The next lemma considers the case where a cmap is mainstream in a’ or soon after, and shows 
that it is mainstream after (time(a’) + e + 4d. 


Lemma 7.10 Let a be an a’-normal execution satisfying (i) (a’,e)-join-connectivity, (ii) (a’, e)- 
recon-readiness, (iii) (a’,2d)-recon-spacing-1, and (iv) (a’, e, 4d)-configuration-viability. 

Assume that t is a time and that e+ 2d <t < étime(a’) +e +2d. If cm is mainstream after t, 
then cm is mainstream after £time(a’) + e+ 4d. 


Proof. Consider configuration co. By configuration-viability, there exists a read-quorum, R € 
read-quorums(co), and a write-quorum, W € write-quorums(co) such that no node in RU W fails 
by time(a’) +e + 4d. 
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Let t) = ftime(a’) +e + 2d. Consider ig € RU W; io does not fail by £time(a’) +e + 4d. Since 
ig performs a join-ack at time 0, by the assumption that a is an a’-normal execution, and since 
t >e+ 2d, io € J(t). Also note that by Lemma 7.6, ig € J(t1). 

Since cm is mainstream after t, cm < fstate(B(t)).cmap;,. Therefore, we know by Lemma 7.6 
that cm < éstate(B(t1)).cmap,;,. By Lemma 7.7, we know that ¢state(6(t1)).cmap;, is mainstream 
after ¢; + 2d. Therefore by Lemma 7.4, cm is mainstream after ¢; + 2d; that is, cm is mainstream 
after Ctime(a’) +e + 4d. 


The next lemma shows the existence of a certain configuration, h', with some particular prop- 
erties. This will be useful in proving Lemma 7.14. 


Lemma 7.11 Leta be an a’-normal execution satisfying: (1) (a’,e)-join-connectivity, (ii) (a’, e)- 
recon-readiness, (iii) (a’, 2d)-recon-spacing-1, and (iv) (a’, e, 4d)-configuration-viability. 

Assume that t and t' are times. Assume that ltime(a’) +e +2d<t<t' — 2d and ftime(a’) + 
e+6d <t'. Assume that cm is mainstream after t. Then there exists a configuration h, with index 
k, with the following properties: 


1. members(h) C J(t’). 
2. For all members i of configuration h that do not fail in B(t'), cm < éstate(B(t’ — 2d)).cmap,. 


3. No successful recon(h,*) event occurs in B(t' — 4d). 


Proof. There are three different sub-cases to consider. 


1. No successful recon event occurs in ((t' — 4d): 
Let h = co. Notice that members(h) C J(t), since ig (the only member of co) completes a 
join-ack at time 0 (by assumption on qa), and t > ¢time(a’)+e+2d. This, then, implies Prop- 
erty 1 by Lemma 7.1. Since ig € J(t) and cm is mainstream after t, em < ¢state(B(t)).cmap,,. 
Therefore, since t < t/ — 2d, by Lemma 7.6, cm < éstate(G(t' — 2d)).cmap,,, as required for 
Property 2. Property 3 holds trivially. 


2. A successful recon event occurs in §(t’ — 4d) after time t: 

Consider the last successful recon event in a that occurs in §(t’—4d); let h be the configuration 
identifier appearing as the second argument in this recon event. Assume that this recon event 
occurs at time trec. Note that t < tree < t'! — 4d. Therefore (since t’ > £time(a’) +e + 6d 
and t! > tree) by Lemma 7.2, members(h) C J(t’), as required for Property 1. Since tree > t, 
Lemma 7.9 shows that cm is mainstream after tye.+2d. Recall that t,¢.+2d < t’/—2d. By the 
mainstream property, for every member, i, of configuration h that does not fail in 6(t’ — 2d), 
cm < éstate(B(tree + 2d)).cmap;; therefore, for each of these members, i, by Lemma 7.6, 
cm < éstate(B(t' — 2d)).cmap,, as required for Property 2. Property 3 holds by the selection 
of the last successful recon event in 3(t’ — 4d). 


3. Neither Case 1 nor Case 2 holds, that is, a successful recon event occurs in (3(t' — 4d), but no 
such recon event occurs after time t: 
Consider the last successful recon event in a that occurs in §(t’—4d); let h be the configuration 
identifier appearing as the second argument in this recon event. Assume that this recon 
event occurs at time tree. Notice, then, that tree < t. (Otherwise, Case 2 would hold.) 
Since t > ¢time(a’) + e + 2d, then by Lemma 7.2, members(h) C J(t). By Lemma 7.6, 
then, members(h) C J(t'), which implies Property 1. Since cm is mainstream after ¢ (and 
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Figure 19: Lemma 7.12 


members(h) C J(t)), for all 7 € members(h) such that no fail; event occurs in f(t), em < 
éstate(G(t)).cmap,;. Since t < t' — 2d, by Lemma 7.6, for all j such that no fail; event occurs 
by time t’ — 2d, cm < éstate(6(t’ — 2d)).cmap,, as required for Property 2. Property 3 holds 
by the selection of the last successful recon event that occurs in 6(t' — 4d). 


Finally we prove the main lemma of this section, showing that if a cmap is mainstream at 
time t, then the cmap is also mainstream at times t’ > t + 2d. There are two cases to consider: (i) 
t > étime(a’) +e+ 2d, and (ii) t < Ctime(a’)+e+2d. Lemma 7.12 shows the first case, Lemma 7.13 
shows the second case, and Lemma, 7.14 presents the overall conclusion. 


Lemma 7.12 Let a be an a’-normal execution satisfying (i) (a’,e)-join-connectivity, (ti) (a’, e)- 
recon-readiness, (777) (a’,2d)-recon-spacing-1, and (iv) (a’, e, 4d)-configuration-viability. 

Assume that t and t' are times. Assume that e+ 2d <t < t' — 2d and ¢time(a’') +e + 6d < t’. 
Additionally assume that t > £time(a’) +e+ 2d. If cm is a mainstream CMap after t, then cm is 
mainstream after t’. 


Proof. By assumption, t > ftime(a’)+e+2d. Lemma 7.11 shows that there exists a configuration, 
h, with index k with the following three properties: 


1. members(h) C J(t’). 
2. For all members 7 of configuration h that do not fail in S(t’), cm < éstate(B(t' — 2d)).cmap,. 
3. No successful recon(h, *) event occurs in ((t’ — 4d). 


Configuration-viability guarantees that some node of configuration fh does not fail until after the 
next configuration is installed. No successful recon(h, *) event occurs in 3(t’ — 4d), by Property 3. 
Therefore some node, 7 € members(h) does not fail in G(t’) (and therefore does not fail in 6(t’—d)), 
by 4d-configuration-viability. By Property 1 of h, node 7 € J(t'). Therefore, by Lemma 7.7, 
éstate(B(t' — 2d)).cmap, is mainstream after ¢’. 

Further, we know by Property 2 that cm < éstate(G(t' — 2d)).cmap;. Therefore by Lemma 7.4, 
cm is mainstream after ¢’. 


The following lemma considers the case where t < ¢time(a’) + e + 2d: 


Lemma 7.13 Let a be an a’-normal execution satisfying (i) (a’,e)-join-connectivity, (ii) (a’, e)- 
recon-readiness, (iii) (a’, 2d)-recon-spacing-1, and (iv) (a’, e, 4d)-configuration-viability. 

Assume that t and t' are times. Assume that e+2d <t < t' — 2d and ftime(a’') +e+ 6d < #’. 
Additionally, assume that t < etime(a’) +e+4+ 2d. If cm is a mainstream CMap after t, then cm is 
mainstream after t’. 
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Figure 20: Lemma 7.13 


Proof. By assumption, t < £time(a’) +e+ 2d. Let t) = ltime(a’) +e +2d. By Lemma 7.10, cm 
is mainstream after t; +2d. By assumption, t, + 2d < t’ — 2d, and ftime(a’) +e + 2d < t, +2d. By 
Lemma 7.12, however, we know that since cm is mainstream after t, + 2d, then cm is mainstream 
after t’. 


The following lemma combines the previous two lemmas into a single conclusion. This lemma is 
the main result of this section, and is used throughout the rest of the proof. 


Lemma 7.14 Let a be an a’-normal execution satisfying (i) (a’,e)-join-connectivity, (ii) (a’, e)- 
recon-readiness, (iii) (a’, 2d)-recon-spacing-1, and (iv) (a’, e, 4d)-configuration-viability. 

Assume that t and t' are times. Assume thate+2d<t<t' —2d and ftime(a’) +e + 6d < t’. 
If cm is a mainstream CMap after t, then cm is mainstream after t’. 


Proof. By Lemmas 7.12 and 7.13. 


7.6 Upgrade-Ready Viability 


In this section, we show the relationship between a configuration being upgrade-ready, and a configu- 
ration being viable. In particular, we prove that if an execution a is (a’,e,22d)-configuration-viable, 
then configuration c(k) is viable until at least 15d after the upgrade-ready(c(& + 1)) event. 

The first lemma shows that soon after a configuration is installed, every node that joined a 
while ago learns about the new configuration. 


Lemma 7.15 Leta be an a'-normal execution satisfying: (1) (a’,e)-join-connectivity, (ii) (a’, e)- 
recon-readiness, (iii) (a’, e, 4d)-configuration-viability. 

Assume that t € R2° is a time, and configuration c(k) is installed at time t. Then there exists 
a CMap, cm, such that cm(k) # L, and cm is mainstream after max(t, £time(a’) + e) + 2d. 


Proof. We first find a node 7 € members(c(k—1)) such that 7 € J(max(t, £time(a’)+e)+2d) and 
4 does not fail in B(max(t, time(a’) + e) +d). Configuration-viability guarantees that there exists 
a read-quorum R € read-quorums(c(k —1)) and a prefix a” of a such that c(k) is installed in a and 
no node in R fails by max(étime(a”), 2time(a’) + e) + 4d. Since configuration c(k) is installed at 
time t, we know that t < £time(a”’), and therefore no node in R fails by max(t, 0time(a’) + e) + 4d. 
Therefore no node in R fails in 8(max(t, £time(a’) + e) +d). Choose some node 7 € R. 

Assume that configuration c(k — 1) is proposed at time tree. We next apply Lemma 7.2 where 
h=c(k—1), t = tree, and t = max(t, Ctime(a’) + e) + 2d: 


e max(t, /time(a’)+e)+2d > trec: c(k—1) is proposed at tree < t, since c(k—1) must be proposed 
prior to configuration c(k — 1) being installed, which must occur prior to configuration c(k) 
being installed; t < max(t, time(a’) + e) + 2d. 


AT 


e max(t, /time(a’) + e) + 2d > Ltime(a’) +e + 2d: Immediate. 


We therefore conclude that members(c(k — 1)) C J(max(t, time(a’) + e) + 2d). Therefore we 
have shown that 7 € members(c(k — 1)), 7 € J(max(t, £time(a’) + e) + 2d), and 7 does not fail in 
B(max(t, £time(a’) +e) +d). 
Since configuration c(k) is installed at time t and 7 € members(c(k—1)), state(B(t)).cmap(k); A 
, by the definition of a configuration being installed, and therefore (by Lemma 7.6) ¢state(8(max(t, €time(a’)+ 
e))).cmap(k); A L. We let cm = éstate(G(max(t, Ctime(a’) + e))).cmap(k);; em(k) A 1, as re- 
quired. 
We next apply Lemma 7.7, where t = max(t, (time(a’) + e) and i = 7: 


e max(t, time(a’) + e) > ltime(a’) + e: Immediate. 
e 7 € J(max(t, Ltime(a’) +e) + 2d): Shown above. 
e j does not fail in 8(max(t, time(a’) + e) + d): Shown above. 


We therefore conclude that éstate(3(max(t, time(a’)+e))).cmap, is mainstream after max(t, 2time(a’)+ 
e) + 2d, that is, cm is mainstream after max(t, Ctime(a’) + e) + 2d. 


The next lemma shows that soon after smaller configurations are installed, a configuration is 
upgrade-ready. 


Lemma 7.16 Let a be ana’-normal execution satisfying: (i) (a’,e)-join-connectivity, (14) (a’, e)- 
recon-readiness, (iii) (a’,2d)-recon-spacing-1, and (iv) (a’, e, 4d)-configuration-viability. 

Let c be a configuration with index k, and assume that for all € < k, configuration c(é) is 
installed in a by time t. 

Then upgrade-ready(k) occurs in B(max(t, £time(a’) + e) + 6d). 


Proof. For every configuration c(¢) with index ¢ < k, let tg be the time at which configuration 
c(€) is installed. Therefore t > max(t;). 

We first show that for all £ < k, there exists a CMap, cm, such that cm,(@) # L and cm, is 
mainstream after max(t, 2time(a’) + e) + 6d. Fix some é < k. 

Lemma 7.15, where t = tg and k = @, shows that there exists a CMap, cmz, such that cme(@) 4 L 
and cm, is mainstream after time max(t, £time(a’) + e) + 2d. 

We next apply Lemma 7.14, where t = max(ty, £time(a’) + e) + 2d and t’ = max(t, Ctime(a’) + 
e) + 6d: 


e max(t, 2time(a’) +e) + 2d > e + 2d: Immediate. 


e max(t;, time(a’) + e) + 2d < max(t, 2time(a’) + e) + 6d — 2d: We know that te < t, and 
Ltime(a’) +e + 2d < Ltime(a’) +e + 4d. 


e max(t, 2time(a’) + e) + 6d > Ltime(a’) +e + 6d: Immediate. 
e cme is mainstream after max(te, Ctime(a’) +e) + 2d: Shown above. 


We therefore conclude that cm, is mainstream after max(t, /time(a’) +e) +6d. We have thus shown 
that for all @ < k, there exists a CMap, cm, such that cm¢(@) # L and cm, is mainstream after 
max(t, £time(a’) + e) + 6d. 

Recall that upgrade-ready(k) is designated as the first event after which (i) all configurations 
with index < k have been installed, and (ii) for all  < k, for all members of configuration c(k — 1) 
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that do not fail prior to the upgrade event, cmap(£) # L. The first component occurs by time f, 
and therefore by time max(t, ftime(a’) + e) + 6d, by assumption. 

We therefore need to show the second part. Fix some node 7 € members(c(k — 1)) such that 
4 does not fail in 6(max(t, £time(a’) + e) + 6d). Fix some £ < k. We apply Lemma 7.2, where 
h = c(k —1), t = max(t, £time(a’) +e) + 6d, and ?’ is the time at which configuration c(k — 1) is 
proposed: 


e max(t, /time(a’) +e) + 6d is > the time at which configuration c(k — 1) is proposed: c(k — 1) 
is proposed prior to time t,_ 1 (the time at which configuration c(k — 1) is installed), which 
is < time t < max(t, Ctime(a’) + e) + 6d. 


e max(t, time(a’) + e) + 6d > Ltime(a’) +e + 2d: Immediate. 


We therefore conclude that members(c(k — 1)) C J(max(t, time(a’) + e) + 6d), and therefore 
j € J(max(t, time(a’) + e) + 6d). 

We know from above that cme is mainstream after max(t, ¢time(a’) + e) + 6d, which implies, 
by the definition of being mainstream, that cmp < £state(G(max(t, £time(a’) + e) + 6d)).cmap (2) ;. 
This in turn implies that ¢state(6(max(t, 0time(a’)+e)+6d)).cmap(£); # L, as required. Therefore 
upgrade-ready(k) occurs in 6(max(t, £time(a’) + e) + 6d). 


The next lemma directly relates the time when all quorums of configuration c(k — 1) fail to the 
time at which upgrade-ready(k) occurs. 


Lemma 7.17 Let a be an a'-normal execution satisfying: (1) (a’,e)-join-connectivity, (ii) (a’, e)- 
recon-readiness, (iii) (a’,2d)-recon-spacing-1, and (iv) (a’, e, 22d)-configuration-viability. 

Let c be a configuration with index k, and assume that the upgrade-ready(k) event occurs at time 
t. Then there exists a read-quorum, R, and a write-quorum, W, of configuration c(k —1) such that 
no node in RUW fails in 8(max(t, time(a’) + e) + 16d). 


Proof. Let a” be the shortest prefix of a such that every configuration with index < k is installed 
in a. Let t’ = ltime(a”). Notice that for all 2 < k, configuration c(£) is installed in G(t’). 

Lemma 7.16, where ¢ = t’ and c and k are as defined above, shows that the upgrade-ready(k) 
event occurs in 6(max(t’, 2time(a’) + e) + 6d), that is, t < max(t’, £time(a’) + e) + 6d. 

Configuration-viability guarantees that there exists a read-quorum, R, and a write-quorum, W, 
of configuration c(&k — 1) such that either (1) no process in RU W fails in a, or (2) there exists 
a finite prefix, Qinstay of a such that for all 2 < k, configuration c(£) is installed in ajnstay and 
no process in RU W fails in a@ by time max(ltime (insta), £time(a’) + e) + 22d. In the former 
case, we are done. We now consider the second case. Since a” is the shortest prefix of a such 
that every configuration with index < k is installed, we know that @” is a prefix of Qjnstaij, and 
therefore t' = ftime(a”) < Ltime(ainstai). Therefore we know that there exists a read-quorum, 
R€ read-quorums(c(k —1)), and a write-quorum, W € write-quorums(c(k —1)), such that no node 
in RUW fails by time max(t’, 0time(a’) + e) + 22d. 

Then, max(t, £time(a’)+e)+16d < max(t’, Ctime(a’)+e)+22d, and as a result, no node in RUW 
fails by time max(t, £time(a’) +e) +16d. That is, no node in RU W fails in G(max(t, £time(a’) + 
e) + 16d). 


The final lemma shows that if no upgrade-ready(k) occurs in a, then configuration c(k — 1) is always 
viable. 
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Lemma 7.18 Let a be ana’-normal execution satisfying: (i) (a’,e)-join-connectivity, (11) (a’, e)- 
recon-readiness, (iii) (a’,2d)-recon-spacing-1, and (iv) (a’, e, 4d)-configuration-viability. 

Let c be a configuration with index k, and assume that no upgrade-ready(k + 1) event oc- 
curs in a. Then there exists a read-quorum, R € read-quorums(c), and a write-quorum, W € 
write-quorums(c), such that no node in RUW fails in a. 


Proof. Assume that for some ¢< k+1, configuration c(¢) is not installed in a. By the definition 
of configuration-viability, then, there exists a read-quorum, R € read-quorums(c), and a write- 
quorum, W € write-quorums(c), such that no node in RU W fails in a. 

Assume, instead, that for every @ < k + 1, configuration c(@) is installed in a. Then by 
Lemma 7.16, an upgrade-ready(k + 1) event occurs in a, contradicting the hypothesis. 


7.7 Configuration-Upgrade Latency Results 


In this section we show that configuration-upgrade operations terminate rapidly, and that any ob- 
solete configuration is rapidly removed. In particular, these results hold in executions that include 
periods of bad behavior. The configuration-upgrade mechanism in RAMBO does not make these 
guarantees. The original RAMBO latency analysis required the assumption of (a’, 00)-configuration- 
viability® for the entire execution. This is an unrealistic assumption in a long-lived dynamic sys- 
tem. As a result of the new configuration-upgrade mechanism, we need to assume only bounded 
configuration-viability to ensure liveness. 

First we state a lemma about configuration-upgrade after the system stabilizes and good be- 
havior resumes. 


Lemma 7.19 Let a be an a’-normal execution. Let t € R2° be a time. Let i be a node that does 
not fail until after max(t, Ctime(a’) + d) + 4d. 

Assume a cfg-upgrade(k); event occurs in a at time t. Additionally, assume that for every 
configuration c(£) such that upg.cmap(@); € C, there exists a read-quorum, Re, and a write-quorum, 
W., of configuration c(£) such that no node in Re U We fails by time t + 3d. 

Then a cfg-upgrade-ack(k); event occurs no later than t + 4d. 


Proof. There are two cases to consider. 


Case 1: t > ftime(a’). At time t, node 7 begins the configuration-upgrade, with phase-number 
Pp, = upg.pnum,;. By triggered gossip, node 7 immediately sends out messages to every node 
in world;. Therefore for every configuration c(¢) such that upg.cmap(); € C, every node 
7 € Re U W; receives a message by time ¢ + d. 


By triggered gossip, then, each of these nodes sends a response with phase-number p;. Each 
response is received by time t + 2d, at which point a cfg-upg-query-fix(k); event occurs. Node 
i then chooses a new phase-number, po, and sets upg.pnum,; = po. 


Immediately, by triggered gossip node 7 sends out messages to every process in world,;, includ- 
ing every node in Ry UW, for every configuration c(é) such that upg.cmap(@); € C. Again, a 
response is sent by time ¢ + 3d, and node 7 receives a response from each with phase-number 
p2 by time t + 4d. Immediately, then, a cfg-upg-query-fix(k) event occurs. This is followed by 
a cfg-upgrade-ack(k), proving our claim. 


® Although we have not formally defined (a’,00)-configuration-viability here, one can understand it to mean (a’, e)- 
configuration-viability for arbitrarily large e. 
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Case 2: t < ftime(a’). At time t, node 7 begins the configuration-upgrade, with phase-number 
pi = upg-pnum,. By occasional gossip, 7 sends out messages to every node in world;. There- 
fore for every configuration c(£) such that upg.cmap(£); € C, every node j € Ry UW, receives 
a message by time max(t, £time(a’) + d) + d. 


By triggered gossip, then, each of these nodes sends a response with phase-number p;. Each 
response is received by time max(t, ¢time(a’) + d) + 2d, at which point a cfg-upg-query-fix(k); 
event occurs. Node 7 then chooses a new phase-number, po, and sets upg.pnum; = po. 


Immediately, by triggered gossip node 7 sends out messages to every process in world,;, includ- 
ing every node in RpUW+, for every configuration c(¢) such that upg.cmap(@); € C. Again, a re- 
sponse is sent by time max(t, £time(a’)+d)+3d, and node i receives a response from each with 
phase-number p2 by time max(t, ¢time(a’)) + 4d. Immediately, then, a cfg-upg-query-fix(k) 
event occurs. This is followed by a cfg-upgrade-ack(k), proving our claim. 


Next, we provide a conditional guarantee that a configuration is viable: if for some time ¢ every 
earlier cfg-upgrade operation completes rapidly within 4d, then every configuration that is extant 
at time ¢ will remain viable until ¢ + 3d. 

We do this in four steps. First, Lemma 7.20 demonstrates that a node with certain good 
properties exists. Second, Lemma 7.21 shows that this certain node with good properties will 
begin an upgrade operation, in certain situations. Third, Lemma 7.22 shows that soon after a 
configuration is upgrade-ready(k), some node completes an upgrade operation on configuration 
c(k). Finally, Lemma 7.23 uses these preliminary lemmas to show that under certain conditions, 
configurations remain viable sufficiently long. 


Lemma 7.20 Let a be an a'-normal execution satisfying (i) (a’, e)-join-connectivity, (ii)(a’, e)- 
recon-readiness, (iii) (a’, e)-upgrade-readiness, (iv) (a’,2d)-recon-spacing-1, (v) (a’, e, 22d)- 
configuration-viability. 

Assume that an upgrade-ready(k2) event occurs at time t for some configuration co and assume 
that kg > 1. Let ky = ko — 1, and c, = c(k i). Then there exists a node i such that the following 
hold: 


1. 4 is a member of configuration c1, 
. i does not fail in B(max(t, ftime(a’) +e +d) + 10d), 


. 7 € J(max(t, 6time(a’') + e+ d) + 8d), 


2 
3 
4. 4€ J(max(t, 2time(a’) + e + 2d)), 
5. 4 performs a join-ack prior to the upgrade-ready(k2) event in a. 


Proof. Lemma 7.17, applied with c = co, k = ko, and t as defined above, implies that there exists 
a read-quorum, R, of configuration c, such that no member of R fails in 8(max(t, time(a’) + e) 
16d). Then we know that no member of R fails in 6(max(t, 2time(a’) +e+d)+ 14d). We therefore 
choose a node i € R C members(c1). We know that 7 does not fail in G(max(t, Ctime(a’) +e +d) 
10d). This 7 satisfies Parts 1 and 2. 

Let t-, be the time at which configuration c, is proposed. Notice that max(t, £time(a’) + e+ 
2d) > te,, because t, the time of the upgrade-ready(Kz), cannot be smaller than ¢,,, the time at 
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which configuration c; is proposed (since an upgrade-ready(k2) event cannot occur until after a 
recon(c;,¢c2) event, which cannot occur until after a recon(*,c,) event). Therefore, Lemma 7.2, 
applied where h = ci, t’ = t-,, and t = max(t, /time(a’) +e + 2d), guarantees that members(c) C 
J(max(t, time(a’)+e+2d)). Since i € members(c,), we know that i € J(max(t, 0time(a’)+e+2d)), 
satisfying Part 4. 

Since max(t, 0time(a’) + e + 2d) < max(t, ftime(a’) + e + d) + 10d (since Ltime(a’) + e + 
2d < ftime(a’) + e+ 10d), Lemma 7.1, applied where ¢ = max(t, ftime(a’) + e + 2d) and t! = 
max(t, £time(a’) +e +d) + 10d, implies that J(max(t, 2time(a’) + e+ 2d)) C J(max(t, £time(a’) + 
e+d)+ 10d), and thus 7 € J(max(t, £time(a’) +e +d) + 10d), satisfying Part 3. 

Finally, notice that recon-readiness requires that 7 performs a join-ack prior to the recon(x, c,) 
event, and therefore prior to the cfg-upgrade(k2) event. This satisfies Part 5. 


The next lemma claims that when a configuration is upgrade-ready, and a node with certain 
properties (as in Lemma 7.20) exists, then either the configuration is removed or an upgrade 
operation begins. 


Lemma 7.21 Let a be an a’-normal execution satisfying (i) (a’, e)-join-connectivity, (ii)(a’, e)- 
recon-readiness, (iii) (a’, e)-upgrade-readiness, (iv) (a’,2d)-recon-spacing-1, (v) (a’, e, 22d)- 
configuration-viability. 

Assume upgrade-ready(k2) occurs at time t and kg > 1. Let ky = ko —1 and cy = c(k — 1). 
Further, assume that node i has the following properties: 


1. 4 is a member of configuration c1, 


2. i does not fail in B(max(t, 2time(a’) +e +d) + 10d), 


3. 4 € J(max(t, Ltime(a’) +e +d) + 8d), 


4. 1 € J(max(t, time(a’) +e + 2d)), 


5. 4 performs a join-ack prior to the upgrade-ready(k2) event. 


Let t' be a time such that t < t’ < max(t, Ctime(a’) +e +d) +13d. Let a” be a prefix of a such 
that: 


1. t' = Ltime(a"’), 
2. an upgrade-ready(k2) event is in a”, 
3. Lstate(a”).upg.phase, = idle. 

Then either: 


1. éstate(G(t')).cmap(k1); = +, or 


2. 4 performs a cfg-upgrade(k’); at time t’, for some k! > kp. 


Proof. If éstate(a’).cmap(k1); = +, then the conclusion holds, since a” is a prefix of 6(t’): 
by Lemma 7.6, ¢state(G(t')).cmap(k,); = +. Assume, then, that state(a”’).cmap(k1); # +. We 
examine in turn the preconditions for cfg-upgrade(k’); just after a” (from Figure 7): 


1. 7€state(a’).failed;; By Part 2 of the assumption on i, we know that i does not fail in 
B(max(t, time(a’) +e +d) + 10d). However, t’ < max(t, £time(a’) + e + d) + 10d, and 
thus 7 does not fail in G(t’). Since a” is a prefix of G(t’), 7 does not fail in a”. 
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2. estate(a”’).status; = active: By Part 5 of the assumption on 7 we know that i performs a 
join-ack prior to the upgrade-ready(k2) event. 


3. lstate(a”).upg.phase; = idle: By assumption, this holds. 


4. VEEN £ < ko: estate(a”’).cmap(é); # L: It suffices to show that by the point in the execution 
at which the upgrade-ready(k2) event occurs, node 7 has already learned of configuration 
c2 and all configurations with smaller indices. Let a” be the prefix of a ending in the 
upgrade-ready(k2) event. Part (ii) of the definition of the upgrade-ready(k2) event guarantees 
that: for all 2 < ke, for all 7 € members(c) that do not fail in a!”, state(a’”).cmap(l); A L. 
Notice that by Part 1 of the assumption about 7, 1 € members(c,) and that by Part 2 of the 
assumption about 7, 7 does not fail in a’”, since ftime(a’”) = t < max(t, 2time(a’) +e 4+ d). 
Therefore we can conclude by part (ii) that for all 2 < ko, &state(a’”).cmap(£); # L. Since 
a” is a prefix of a” (by assumption that upgrade-ready(k2) is included in a”), by Lemma 7.5 
we know that for all £ < ko, €state(a”).cmap(£); # L, as desired. 


5. éstate(a”’).cmap(k2); € C: By assumption, éstate(a”).cmap(k1); # +. Invariant 4.3 then im- 
plies that £state(a”).cmap(k2); # +, since ky < kp. Part 4, above, shows that &state(a”).cmap(k2); # 
., thus implying the desired result. 


6. éstate(a”’).cmap(k 1); € C: By assumption, ¢state(a”).cmap(k1); #4 +. Part 4, above, shows 
that &state(a”).cmap(k1); # L, since ky < ko, thus implying the desired result. 


Since enabled events occur in zero time (by assumption), either the event becomes disabled, in which 
case fstate(G(t’)).cmap(k); = +, satisfying Part 1 of the conclusion, or at time t’ = ftime(a”) a 
cfg-upgrade event for some configuration c with index k’ > kz occurs, satisfying Part 2 of the 
conclusion. 


The next lemma conditionally guarantees that soon after a new configuration is upgrade-ready, the 
old configuration is removed. 


Lemma 7.22 Let a be an a’-normal execution satisfying (i) (a’, e)-join-connectivity, (ii)(a’, e)- 
recon-readiness, (iii) (a’, e)-upgrade-readiness, (iv) (a’,2d)-recon-spacing-1, (v) (a’, e, 22d)- 
configuration-viability. 

Assume that t € R2° is a time such that t > ftime(a’) +e + 14d. Assume that c, is a 
configuration, and for some finite prefix a” of a, where t = Ltime(a"), for some node i € J(t) that 
does not fail in a", for some index ky, lstate(a”).cmap(k1); = c1- 

Also, we assume the Upgrades-Complete Hypothesis: for every cfg-upgrade(*); event that occurs 
ina at some time tupg < t at some node j € J(max(tupg, Ltime(a’)+e+2d)) where j does not fail in 
B(max(tupg, £time(a’)+e+d)+4d), a matching cfg-upg-ack(*); occurs by time max(tupg, £time(a’) + 
e+d)+4d. 

Assume that an upgrade-ready(k, + 1) event occurs at time t! < t— 13d. Let kg = ky +1 
and cg = c(k2). Then for some node i’ € J(max(t’, £time(a’) +e + d) + 8d) that does not fail in 
B(max(t’, £time(a’) +e + d) + 10d), &state(G(max(t’, £time(a’) + e + d) + 8d)).cmap(k,)y = +. 


Proof. We first identify a node, 2’, that is suitable. Then we show that i’ completes an upgrade 
operation in the alotted time. 

We apply Lemma 7.20, where ¢ = t’, and therefore conclude that there exists a node 7’ with the 
following five properties: 
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4, 


5. 


. # is a member of configuration c,, 


. ' does not fail in 6(max(t’, 2time(a’) + e + d) + 10d), 


.  € J(max(t’, £time(a’) +e + d) + 8d), 


i’ € J(max(t’, 2time(a’) + e + 2d)), 


i’ performs a join-ack prior to the upgrade-ready(k2) event. 


Notice that Part 2 and Part 3 satisfy the first two requirements for 7’ in the conclusion of this 
lemma. It remains to show that i’ marks configuration c,; as + at the appropriate point. 

We consider what happens at time max(t’, ftime(a’) +e +d). Let a” be the prefix of a that 
is the longer of the following two prefixes: (i) G(¢time(a’) + e +d), or (ii) the shortest prefix of a 
that includes the cfg-upgrade(k2) event. Notice that @time(a’”) = max(t’, ftime(a’) +e +d), and 
that the cfg-upgrade(kz) event is in a’”. 


If ¢state(a’’)).cmap(k1)y = +, then the claim is immediate: Lemma 7.5 implies that ¢state(a!”).cmapy < 
éstate(G(max(t’, 2time(a’) + e + d) + 8d)).cmap,;, since £time(a’”) = max(t’, (time(a’) +e +d) < 
max(t’, /time(a’)+e+d)+8d. Therefore, if &state(a’”).cmap(k,) = +, then éstate(G(max(t’, £time(a’)+ 


e +d) +8d)).cmap(k ); = +. 
We thus assume that ¢state(a’”).cmap(k1) 4 +, and consider what happens at time max(t’, time(a’)+ 


e +d). There are now two cases to consider: 


1. 


2. 


éstate(a’").upg.phase, = idle or 


lstate(al”).upg.phase, # idle. 


Case 1: Assume that éstate(a’”).upg.phase, = idle. We apply Lemma 7.21, where t = ¢’, t! = 


max(t’, ftime(a’) +e +d), a” =a", and 7’ is as chosen above: 


et’ < max(t’, £time(a’) +e +d) < max(t’, ftime(a’) +e +d) + 13d: immediate, 

e i’ satisfies the criteria, by the properties of 7’ above, 

e ftime(a’”’) = max(t’, time(a’) +e +d) and upgrade-ready(k2) occurs in a”: by the way 
in which a” was chosen, 


e éstate(a’).upg.phase, = idle: by the case assumption. 


From this lemma, we conclude that either: 


1. éstate(G(max(t’, 2time(a’) + e + d))).cmap(ki)y7 = +, or 

2. i’ performs a cfg-upgrade(k’), at time max(t’, time(a’) +e +d), for some k! > ky. 
In the first case, where ¢state(6(max(t’, 2time(a’) + e + d))).cmap(k1)y = +, we are done: 
Lemma 7.6 implies that ¢state(6(max(t’, 2time(a’) + e+ d) + 8d)).cmap(k1) = +. Consider 


the second case, that is, 7’ performs a cfg-upgrade(k’), at time max(t’, 2time(a’) +e + d), for 
some k! > ko. 


We then apply the Upgrades-Complete Hypothesis, where j = i’ and typ, = t’; notice that: 


e i’ € J(max(t’, Ltime(a’) +e + 2d)): by 4h property of 4’, 
e i’ does not fail in 6(max(t’, ftime(a’) + e + d) + 4d): by Part 2 of the way in which 2’ 
was chosen, and 
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e max(t’, ftime(a’) +e+d) < t: t!+13d < t, by assumption, and ftime(a’) +e + 14d < t, 
by assumption, and therefore max(t’, £time(a’) +e +d) + 13d < t. 


Therefore, by the Upgrades-Complete Hypothesis we conclude that a cfg-upg-ack(k’); occurs 
by time max(t’, £time(a’) +e+d)+4d. Since k’ > ko, then by the precondition of a cfg-upg-ack 
operation we know that éstate(G(max(t’, 0time(a’) +e+d) +4d).cmap(k 1) = +. Lemma 7.6 
implies that ¢state(G(max(t’, 2time(a’) + e + d) + 8d).cmap(k1)y = +, as desired. 


Case 2: Assume that éstate(a’").upg.phase, # idle. For this to occur, a cfg-upgrade(k’),, event 


must occur prior to the upgrade-ready(k2) event in a with no matching cfg-upg-ack(k’), event 
prior to the upgrade-ready(k2) event, where k’ = ¢state(a”).upg.target,,. Otherwise, if there 
were no ongoing upgrade operation, 7’ would be idle. Let t; be the time at which this earlier 
cfg-upgrade(k’);- operation occurs. 


We can then apply the Upgrades-Complete Hypothesis, where j = i’ and typg = t1; notice 
that: 


e i’ € J(max(ty, 2time(a’) +e + 2d)): Lemma 7.3, applied where ¢ = t; and i = 7’, shows 
that i’ € J(max(t, 2time(a’) +e + 2d)). 

e 7’ does not fail in 8(max(ty, 2time(a’) + e+ d) + 4d): By Part 2 of the way in which 
i’ was chosen, 7’ does not fail in 6(max(t’, 2time(a’) + e + d) + 10d). Notice that t; < 
max(t’, £time(a’) + e +d), since the earlier upgrade event occurs in a” prior to the 
upgrade-ready(k2) event. Therefore 2’ does not fail in 6(max(t, 2time(a’) +e +d) +4d). 


e max(t,, 2time(a’)+e+d) < t: Again, notice that max(t1, 2time(a’)+e+d) < max(t’, £time(a’)+ 


e +d), since t, < t’. Also, t/ + 13d < t, by assumption, and ftime(a’) +e + 14d < t, by 
assumption. Therefore, max(t’, /time(a’)+e+d) < t, implying that max(t1, Ctime(a’) + 
e+d)<t. 


We can then conclude that a cfg-upgrade-ack(k’),, occurs in a by time max(ty, time(a’) + 
e+d)+4d < max(t’, ftime(a’) + e + d) + 4d. If k’ > ko, then by the precondition of the 
cfg-upgrade-ack(k’) action, i’ marks cmap(k,) = +, and we are done. 


Otherwise, we apply Lemma 7.21 to show that another cfg-upgrade operation begins: let te 
be the time at which the cfg-upgrade-ack(k’);, occurs and a2 be the prefix of a ending in the 
cfg-upgrade-ack(k’);, event. Notice that: 


e t! < max(to, ftime(a’) +e +d): By the way in which the cfg-upgrade(k’) was chosen, it 
has to complete no earlier than t’. 

e max(tg, ftime(a’) +e +d) < max(t’, time(a’) +e +d) + 13d: Above, we showed 
that that cfg-upgrade-ack(k’), occurs by max(t’, £time(a’) + e +d) + 4d, that is, tg < 
max(t1, £time(a’) +e +d) +4d < max(t’, £time(a’) +e+d) +4d, since t; < t’. Therefore, 
to < max(t’, £time(a’) +e +d) +13d. Also, £time(a’) +e+d < ltime(a’) +e + 14d. 


Then we apply Lemma 7.21 with t = #’, t’ = max(to, /time(a’) +e +d), a” = ag, and 7’ as 
chosen above: 

et! < max(tg, £time(a’) +e +d) < max(t’, £time(a’) +e +d) + 13d: as shown above, 

e i’ satisfies the criteria, by the properties of 2’ above, 


e ftime(az) = max(te, £time(a’) +e + d) and upgrade-ready(k2) occurs in a”: by the way 
in which a2 was chosen and the fact that the cfg-upgrade-ack(k’);, must come after the 
upgrade-ready(k2) event, 
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e fstate(a2).upg.phase, = idle: by the effect of the cfg-upg-ack(k’);, event that is the last 
event in a”. 


We then conclude that either: 


1. €state(G(max(te, Ctime(a’) + e + d))).cmap(k1)y = +, or 
2. i’ performs a cfg-upgrade(k”);: at time max(tg, ftime(a’) +e +d), for some k” > kp. 


Again, if the first case holds, we are done: since tg < max(t’, time(a’) + e + d) + 8d, 
Lemma 7.6 implies that state (6(max(t’, 2time(a’) + e + d) + 8d)).cmap(ki); = +. There- 
fore, we can assume that the second part holds, and i’ performs a cfg-upgrade(k”); at time 
max(to, £time(a’) +e +d), for some k” > ko. 


Once more, we apply the Upgrades-Complete Hypothesis, where j = i’ and tupg = t2; notice 
that: 


e 7’ € J(max(to, /time(a’) + e + 2d)): Recall that i’ € J(max(t), 2time(a’) + e + 2d)), 
above. Since max(t1, time(a’) +e +2d) < max(tg, £time(a’) +e+2d) (ie., the upgrade 
begins before it completes), by Lemma 7.1, where t = max(t1, /time(a’)+e+2d) and t! = 
max(to, ltime(a’)+e+2d), J(max(t, £time(a’)+e+2d)) C J(max(te, Ctime(a’)+e+2d)), 
implying that i’ € J(max(t2, time(a’) + e + 2d)). 

e i’ does not fail in B(max(to, 2time(a’) +e + d) + 4d): By Part 2 of the way in which 
i’ was chosen, 7’ does not fail in 6(max(t', 2time(a’) + e + d) + 10d). Notice that tg < 
max(t’, 2time(a’)+e+d)+4d, as shown above. Therefore max(tg, £time(a’)+e+d)+4d < 
max(t’, 2time(a’) +e +d) + 8d, and as a result 7’ does not fail in G(max(to, time(a’) + 
e +d) + 4d). 

e max(tg, ftime(a’)+e+d) < t: Again, notice that max(te, 2time(a’)+e+d) < max(t’, time(a’)+ 
e+d)+4d. Also, t'+13d < t, by assumption, and £time(a’)+e+d+13d < t, by assump- 
tion. Therefore, max(t’, /time(a’) +e +d) + 13d < t. Therefore, max(to, ftime(a’) +e+ 
d) < max(t’, £time(a’) + e + d) + 4d < t — 9d, as desired. 


We can then conclude that a cfg-upgrade-ack(k”); occurs in a@ by time max(ta, Ctime(a’) + 
e+d)+4d < max(t’, ftime(a’) +e +d) + 8d. Since k” > ko, then by the precondition 
of the cfg-upgrade-ack(k’) action, i’ marks cmap(k,) = +, and Lemma 7.6 implies that 
fstate(G(max(t’, 2time(a’) + e+ d) + 8d)).cmap(k1) = +. 


In the next lemma, we provide a conditional guarantee that a configuration remains viable. 


Lemma 7.23 Let a be an a'-normal execution satisfying (i) (a’, e)-join-connectivity, (ii)(a’, e)- 
recon-readiness, (iii) (a’, e)-upgrade-readiness, (iv) (a’,2d)-recon-spacing-1, (v) (a’, e, 22d)- 
configuration-viability. 

Assume that t € R2° is a time such that t > ftime(a’) +e + 14d. Assume that c, is 
a configuration, and for some finite prefix a” of a, where t = ltime(a”’), for some node i € 
J(max(t, ftime(a’)+e+2d)) that does not fail in a’, for some index ky, &state(a").cmap(k1); = cr. 

Also we assume the Upgrades-Complete Hypothesis: for all cfg-upgrade(*); events that occur in 
a at some time tupg < t at some node j € J(max(tupg, Ltime(a’) +e+2d)) where j does not fail in 
B(max(typg, £time(a’)+e+d)+4d, a matching cfg-upg-ack(*); occurs by time max(typg, £time(a’) + 
e+d)+4d. 
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Then there exists a read-quorum, R € read-quorums(c,), and a write-quorum, W € write-quorums (cy), 
such that no node in RUW fails in B(t + 3d). 


Proof. Let ky = ki +1, and let co = c(k2). First, consider the case where no upgrade-ready(k2) 
event occurs in a. We apply Lemma 7.18, where c = c, and k = kj; this implies, then, that there 
exists a read-quorum, R € read-quorums(c1), and a write-quorum, W € write-quorums(ci), such 
that no node in RU W fails in a. 

Next, consider the case where an upgrade-ready(k2) event occurs in a. Let t’ be the time at 
which the upgrade-ready(k2) event occurs. We claim that upgrade-ready(k2) occurs no earlier than 
t — 13d. That is, t! + 13d > t. 

Assume, in contradiction, that t' + 13d < t. We now apply Lemma 7.22 to conclude that there 
exists a node i’ € J(max(t’, time(a’) + e + d) + 8d) that does not fail in G(max(t’, 2time(a’) + e+ 
d) + 10d) such that £state(G(max(t’, 2time(a’) +e + d) + 8d)).cmap(k1); = +. 

We now show that the information about configuration c,’s removal is propagated from node 7’ 
to node 7. That is, we show the following: 

Claim: ¢state(a”).cmap(k1); = +. 
Proof of claim: We do this in three steps. First, we show that ¢state(6(max(t’, 0time(a’) + 
e +d) +8d)).cmap, is mainstream after max(t’, 2time(a’) +e +d) + 10d. Second, we show that 
éstate(G(max(t’, £time(a’) +e +d) +8d)).cmap,; is mainstream after t — d. Third, we conclude that 
éstate(a”).cmap(k1); = +. 

Step 1: We already know that 7’ € J(max(t’, 2time(a’) + e + d) + 8d), and does not fail in 
B(max(t’, £time(a’) +e + d) + 10d). We then apply Lemma 7.7, where t = max(t’, £time(a’) +e + 
d) + 8d, andi =7: 


e max(t’, time(a’) +e +d) + 8d > Ltime(a’) + e: Immediate. 


e i’ € J(max(t’, Ctime(a’) +e +d) +8d+ 2d): i’ € J(max(t’, Ctime(a’) + e +d) + 8d), as shown 
above, therefore this follow from Lemma 7.1, where t = max(t’, time(a’) +e +d) + 8d and 
t’ = max(t’, time(a’) +e + d) + 10d. 


e i’ does not fail in 6(max(t’, time(a’)+e+d)+8d+d), since 7’ does not fail in 6(max(t’, 2time(a’)+ 
e +d) + 8d + 2d) as shown above. 


Therefore we can conclude that ¢state(G(max(t’, £time(a’) + e + d) + 8d)).cmap, is mainstream 
after max(t, /time(a’) + e + d) + 10d. 

Step 2: We have assumed above that t’ < t — 13d, that is, t’ +10d < t-—d-— 2d. Also, 
we have assumed that time(a’) + e + 14d < t, that is, Ctime(a’) +e +d+4+ 10d < t—d-— 2d. 
Therefore, max(t’, 2time(a’) + e + d) + 10d < t — 3d. We now apply Lemma 7.14, where ¢ = 
max(t’, £time(a’)+e+d)+10d, t’ = t—d, and cm = éstate(G(max(t’, Ctime(a’)+e+d)+8d)).cmap,r: 


e e+ 2d < max(t’, /time(a’) +e + d) + 10d, 
e max(t’, (time(a’) +e +d) + 10d < t — 3d, 


e ¢state(G(max(t’, £time(a’) + e +d) + 8d)).cmap, is mainstream after max(t, £time(a’) + e+ 
d) + 10d. 


We therefore conclude that ¢state(6(max(t’, @time(a’) + e + d) + 8d)).cmap, is mainstream after 
t—d. 

Step 3: Notice, then, that by assumption 7 € J(t) and i does not fail in 6(t — d). Therefore 
by the definition of mainstream, fstate(G(max(t’, 2time(a’) + e + d) + 8d)).cmap, < éstate(B(t — 
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d)).cmap;. Lemma 7.6 then implies that ¢state(8(t — d)).cmap, < éstate(a”).cmap,;, since B(t — d) 


is a prefix of a”. Therefore, £state((max(t’, 2time(a’) + e + d) + 8d)).cmap,; < lstate(a”’).cmap,. 


Since éstate(8(max(t’, £time(a’) +e +d) + 8d)).cmap(k1)y = + (as shown above), this means that 
éstate(a").cmap(k1); = +, as claimed above, concluding Step 3. 
This claim that state(a”).cmap(k1); = +, though, leads to a contradiction: by assumption of 


this lemma, state (a’’).cmap(k 1); = c,. Therefore, we conclude that our assumption that t’ < t-13d 
is incorrect: that is, we must have t’ > t — 13d. That is, we have shown that the upgrade-ready(k2) 
event occurs at most 13d prior to time ft. 

We now apply Lemma 7.17, where c = c2, k = ko, and t = t’, to conclude that there exists a 
read-quorum, R, and a write-quorum, W, of configuration c, such that no node in RU W fails in 
GB(max(t’, £time(a’) + e) + 16d). Above we showed that t’ + 13d > t, therefore t’ + 16d > ¢ + 3d, 
which implies that max(t’, 2time(a’) + e) + 16d > t+ 3d. Therefore, we can conclude that there 
exists a read-quorum, R, and a write-quorum, W, of configuration c, such that no node in RUW 
fails in 6(t + 3d). 


The next two lemmas claim that every configuration-upgrade operation completes soon after it 
begins, or soon after the network stabilizes. The first lemma handles the case where the upgrade 
begins before the network stabilizes, or during stabilization. The second lemma handles the general 
case, for all t. 


Lemma 7.24 Let a be ana'-normal execution satisfying: (i) (a’, e)-join-connectivity, (ii) (a’, e)- 
recon-readiness, (iii) (a’,2d)-recon-spacing-1, (iv) (a’, e, 22d)-configuration-viability. 

Assume that t € R2° is a time such that t < ftime(a’) +e + 14d, and that a cfg-upgrade(k); 
occurs at time t at node i. Assume that node i € J(t) and thati does not fail in B(max(t, time(a’)+ 
d) + 4d). 

Then a cfg-upg-ack(k); occurs no later than time max(t, £time(a’) + d) + 4d. 


Proof. Let y be the configuration-upgrade operation associated with the cfg-upgrade(k) action. 
Lemma 7.19 shows that proving the following is sufficient to prove the lemma: for every configura- 
tion in removal-set(y) there exists a read-quorum, R and a write-quorum, W, such that no node 
in RUW fail by time max(t, £time(a’) + d) + 3d. 

Consider any configuration, c, with index k, in removal-set(y). If t, is the time at which 
configuration c(k; + 1) is installed, configuration-viability ensures that configuration c, does not 
fail until max(t1, @time(a’) + e) + 22d. Notice that time(a’) + e + 22d > t+ 3d, since t < 
Ltime(a’) +e + 14d. Therefore, this guarantees that there exists a read-quorum, R, and a write- 
quorum, W for configuration c; such that no node in RUW fails until after 2time(a’) + e + 22d > 
max(t, £time(a’) + d) + 3d. 


Lemma 7.25 Leta be ana’-normal execution satisfying: (i)(a’, e)-join-connectivity, (11) (a’, e)- 
recon-readiness, (iii) (a’,2d)-recon-spacing-1, (iv) (a’, e, 22d)-configuration-viability. 

Assume that t € R2° is a time, and that a cfg-upgrade(k); occurs in a at time t at node i. 
Assume that node i € J(t) and that i does not fail in 8(max(t, £time(a’) + e+ d) + 4d). 

Then a cfg-upg-ack(k); occurs no later than time max(t, €time(a’) + e +d) + 4d. 


Proof. We prove this lemma by proving a stronger statement by strong induction on the number 
of cfg-upgrade events in a: if a cfg-upgrade(*); event occurs in a at some time typg < t at some 
node j € J(tupg), and j does not fail in B(max(typ,, 2time(a’) + e + d) + 4d), then a matching 
cfg-upg-ack(«); occurs no later than time max(typ,, time(a’) +e +d) + 4d. 
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As this is strong induction, we now examine the inductive step. Consider configuration-upgrade 
y, the k + 1% upgrade operation in a that occurs at time tupg < t at node j € J(t) that does 
not fail in B(max(typg, Ctime(a’) + e + d) + 4d). Assume, inductively, that if 7 is one of the 
first k upgrade operations that occurs at time ¢t’ < t at some node 7’ € J(t’) that does not fail 
in B(max(t’, £time(a’) + e + d) + 4d), then a matching cfg-upg-ack(*) occurs no later than time 
max(t’, /time(a’) +e + d) + 4d. There are two cases to consider. 


Case 1: tupg < Ltime(a’) +e + 14d. 
Recall that the cfg-upgrade event occurs at node j € J(tupg) where j does not fail in 
B(max(tupg, £time(a’) +e+d)+4d). Lemma 7.24 shows that a cfg-upg-ack(k); occurs by time 
max(tupg, time(a’) + d) + 4d < max(tupg, 2time(a’) + e + d) + 4d. 


Case 2: typ > ftime(a’) + e+ 14d. 
Lemma 7.19 shows that proving the following is sufficient to prove the lemma: for every 
configuration in removal-set(y) there exists a read-quorum, R and a write-quorum, W, such 
that no node in RU W fails in B(max(tupg, 2time(a’) + d) + 3d). Let a” be the prefix of a 
ending with the cfg-upgrade event y. Fix some configuration c € removal-set(y) with index 
k; that is, 2state(a”).cmap(k); = c. We now apply Lemma 7.23, where cj = c, kj = k, a is 
as just defined, and t = tupg: 


© tupg > Ctime(a”) +e + 14d. 
© tupg = Ltime(a”). 


e fstate(a").cmap(k); = c, since c € removal-set(y) and a” is the execution ending with 
the event ¥. 


e j € J(max(typg, Ctime(a’) + e + 2d)), since 7 € J(tupg) and tupg > Ctime(a’) + e + 14d. 


e Upgrades-Complete Hypothesis: for every cfg-upgrade(*); event that occurs in a at 
some time t’ < typg at some node j’ € J(max(tupg, £time(a’) + e + 2d)) where j’ does 
not fail in B(max(tupg, &time(a’) +e +d) +4d), a matching cfg-upgrade,, occurs by time 
max(typg, time(a’) +e +d) +4d: this is the inductive hypothesis, since any cfg-upgrade 
occuring at time t’ < typg must be one of the first k upgrade events. 


Therefore, we conclude that there exists a read-quorum, R € read-quorums(c), and a write- 
quorum, W € write-quorums(c), such that no node in RU W fails in 6(t + 3d). Since this is 
true for all c € removal-set(7), this then shows the desired result. 


We next present two corollaries that follow from these lemmas. First, we present the unconditional 
version of Lemma 7.23: 


Corollary 7.26 Let a be an a’-normal execution satisfying (i) (a’, e)-join-connectivity, (ii)(a’, e)- 
recon-readiness, (iii) (a’, 2d)-recon-spacing-1, (iv) (a’, e, 22d)-configuration-viability. 

Assume that t € R2° is a time. Assume that c is a configuration, and for some finite prefix 
a” of a where t = Ltime(a”), some node i € J(t) that does not fail in a”, for some index k, 
éstate(a").cmap(k); = c. 

Then there exists a read-quorum, R, and a write-quorum, W, such that no node in RUW fails 
in B(max(t, 2time(a’) +e +d) + 3d). 
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Proof. If t > étime(a’') + e+ 14d, then we show that the result follows from Lemma 7.25 and 
Lemma, 7.23. We apply Lemma 7.25 where c; = c, kj = k: notice that Lemma 7.23 assumes that: 


e t > Ltime(a’) +e+ 14d: By assumption. 

e ¢ = ftime(a”): By assumption. 

e éstate(a”’).cmap(k); = c: By assumption. 

e 7 € J(max(t, £time(a’) +e + 2d)): t > Ltime(a’) +e + 14d. 
e i does not fail in a’: By assumption. 


e Upgrade-Completes Hypothesis: Fix some cfg-upgrade(*); event that occurs at time tupg < t 
at node j € J(max(tupg, Ctime(a’) + e + 2d) where j does not fail in 6(max(typg, 2time(a’) + 
e+d)+4d). We apply Lemma 7.25, where t = typg and i = j. (Notice that 7 € J(tupg) by 
Lemma 7.1.) We therefore conclude that a cfg-upgrade(*); occurs no later than max(tyupg, 2time(a’)+ 
e + d) + 4d, as required by the conclusion of the Upgrade-Completes Hypothesis. 


We thus conclude that there exists a read-quorum, R € read-quorums(c) and a write-quorum, 
W € write-quorums(c) such that no node in RUW fails in G(t+3d). Since t > £time(a’) +e + 14d, 
this implies that no node in RU W fails in B(max(t, Ctime(a’) + e + d) + 3d). 

Alternatively, if t < &time(a’) +e + 14d, configuration-viability guarantees that there exists a 
read-quorum, R, and a write-quorum, W, such that no node in RUW fails in 8 (£time(a’) +e+22d), 
and again the result follows. 


The second corollary guarantees the liveness of the system; that is, the following corollary shows 
that read and write operations always terminate eventually: 


Corollary 7.27 Leta be ana’-normal execution satisfying (i) (a’, e)-join-connectivity, (ii)(a’, e)- 
recon-readiness, (iii) (a’,2d)-recon-spacing-1, (iv) (a’, e, 22d)-configuration-viability. 

Assume that t € R2°. Assume that at time t, for some i € J(t) that does not fail in a’, a read; 
or write; occurs ina. Then the operation eventually completes. 


Proof. The read or write operation completes if each phase of the operation completes. Let 7 be 
the read;, write;, query-fix;, or recv; action that sets op.cmap to cmap, beginning the phase. Each 
phase completes when for all £: op.cmap(£); € C, 7 has sent a gossip message to an appropriate 
quorum of nodes in c(¢), and received a response. The only way an operation can fail to terminate, 
then, is if there does not exist a non-failed read-quorum or a write-quorum of some configuration 
in op.cmap. 

Assume that c is a configuration with index k such that op.cmap(k); is set to c at some 
time ¢’ after 7, and before the phase completes. Then for some a” where t! = ¢time(a’), 
éstate(a).cmap(k); = c, since op.cmap is set by copying a truncated version of cmap;. By Corol- 
lary 7.26, there exists a read-quorum, R, and a write-quorum, W, such that no node in RUW fails 
in 6(max(t, £time(a’) +e+d)+3d). No later than time max(t, £time(a’)+e+d) +d, node i sends a 
gossip message to every node in RUW. By time max(t, £time(a’)+e+d)+2d the message is received 
by every node in RUW, and each node sends a response to 7. By time max(t, ¢time(a’)+e+d)+3d, 
node i receives the response, and RUW C acc. Therefore, for all configurations the read and write 
quorums survive long enough, and so the phase completes. 


"More specifically, we are assuming that i does not fail until after the operation terminates; since we do not here 
bound how long the operation may take, we instead assume that i does not fail in a. Obviously i failing after the 
operation completes has no effect on the operation completing. 
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7.8 Read-Write Latency Results 


In this section we state and prove the main result of the latency analysis: if an execution contains 
a period of time of good behavior, and if this section of the executions is 22d-configuration-viable, 
then all read and write operations terminate, and terminate within 8d. Notice that in the original 
RAMBO paper, a similar result required the stronger assumption of oo-configuration-viability, an 
arbitrarily unbounded failure assumption, depending on events earlier in the execution. Here there 
is no dependency on earlier events: the algorithm is guaranteed to stabilize rapidly, as soon as the 
network stabilizes. 

We need one more lemma. This lemma shows that once a report(c) action occurs for some 
configuration with index k, then soon every node has set cmap(¢) # L, for all 2 < k. This will 
allow us to show that if a read or write operation begins long enough after a certain report(c) 
operation, then it cannot be interrupted by learning about new configurations with smaller indices. 


Lemma 7.28 Let a be an a'-normal execution satisfying: (1) (a,e)-join-connectivity, (ii) (a’, e)- 
recon-readiness, (iii) 6d-recon-spacing, (iv) (a’, e, 4d)-configuration-viability. 

Assume that a contains decide events for infinitely many configurations. Let £ be a configuration 
index. Let c, be the configuration with index £, and co be the configuration with index £+ 1. 

Let i be the node at which the first recon(ci, c2) event, 7, occurs. Let t be the time at which the 
report(c1); event, d, occurs. 

Then there exists a CMap, cm, such that: 


1. cm(@) 4 L, and 
2. cm is mainstream after max(t, 2time(a’) + e + d) + 6d. 


Proof. There are two cases to consider. In each case, we first demonstrate an appropriate cm: 
we identify a node that performs a report(c,) and does not fail too soon. We then show that the 
cmap of that node is mainstream after max(t, /time(a’) + e + d) + 6d. 


Case 1: recon(c),c2); occurs at some time < ftime(a’) +e 4+ 2d. 
In this case, we use the Recon-Spacing-2 assumption to identify a node with an appropriate 
cmap, and then use configuration-viability to show that this node survives long enough for 
its cmap to become mainstream after £time(a’) + e + 4d, which then allows us to show that 
its cmap is mainstream after max(t, 2time(a’) +e +d) + 6d. 


By the Recon-Spacing-2 assumption, there exists a write-quorum, W € write-quorums(c1), 
such that for every node j € W, a report(ci); occurs in a prior to 7, the recon event that 
proposes configuration co. By configuration-viability, there exists some node 7 € W that does 
not fail by time £time(a’) +e + 4d, since there exists some read-quorum, R, that does not fail 
by time ftime(a’) +e + 4d, and by assumption RN W 0. 


We now show that cmap, satisfies Property 1 after ¢time(a’) + e + 2d. Notice that: 
state (G(time(m))).cmap(£); A L, 


since the report action notifies 7 of the configuration c, prior to 7. By assumption we know that 
time(m) < ftime(a’)+e+2d. Therefore we know that ¢state(6(Ltime(a’)+e+2d)).cmap; # L. 
Let cm = ¢state(G(Etime(a’) + e + 2d)).cmap;. We know, then, that cm(£) # 1, as desired. 


Next we show that cm is mainstream after £time(a’) + e + 4d. We apply Lemma 7.7, where 
i=j,t = ltime(a’) +e + 2d: 
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e 5 © J(Ltime(a’) +e + 4d): If € = 0, then 7 = ip and we have, by assumption, that io 

performs a join-ack;, at time 0, immediately implying the statement by the definition of 
J. 
Otherwise, we apply Lemma 7.2, where h = c), t! = time(recon(c(é — 1),c1)), and 
t = ltime(a’) +e + 2d. Notice that étime(a’) + e + 2d > time(recon(c(é — 1), c1)) since 
ltime(a’) +e + 2d > time(m), and time(m) > time(recon(c( — 1),c1)). We therefore 
conclude that members(c;) C J(£time(a’) + e + 2d). In particular, this means that 
4 € J(Ltime(a’) +e + 2d). Next we apply Lemma 7.1, where t = ftime(a’) +e 4+ 2d and 
t' = ltime(a’) +e +4d to see that 7 € J(Ltime(a’) + e + 4d). 

e ftime(a’) +e + 2d > Ltime(a’) + e: Immediate. 

e j does not fail in 8(£time(a’) +e + 3d): as shown above j does not fail in 8(£time(a’) + 
e + 4d), by choice of 7 and configuration-viability. 


We then conclude, since cm = éstate(B(ftime(a’) + e + 2d)).cmap,;, that cm is mainstream 
after Ctime(a’) +e + 4d. 
We next apply Lemma 7.14, where t = ¢time(a’) +e + 4d, t’ = max(t, Ctime(a’) +e+d) + 6d, 
and cm is as defined above: 

e ce +2d < Ltime(a’) +e + 4d: Immediate. 

e ftime(a’) +e+4d < max(t, Ltime(a’) +e +d) + 6d — 2d: Immediate. 


e cm is mainstream after /time(a’) + e+ 4d: As shown above. 


Therefore, we conclude that cm is mainstream after max(t, £time(a’)+e+d) + 6d, as desired. 


Case 2: recon(c,,c2); occurs at some time > ftime(a’) + e + 2d. 
We first notice that 7 has been notified of configuration c; and then show that the cmap of 7 
is mainstream after max(t, 2time(a’) + e+ d) + 6d. 


Notice that ¢state(8(t)).cmap(£); 4 L, since the report(c,); event notifies 7 of configuration 
Cl. 


We now apply Lemma 7.7, where 7 is as defined above and t = max(t, £time(a’) +e +d), to 
show that cm is mainstream after max(t, ¢time(a’) + e + d) + 2d: 


e max(t, ftime(a’) +e +d) + 2d > Ltime(a’) +e: Immediate. 

e i € J(max(t, £time(a’) +e + d) + 2d): We apply Lemma 7.2, where h = cy, t’ is the 
time at which c, is proposed, and t = max(t, time(a’) +e +d) + 2d. Notice that 
max(t, 2time(a’) +e +d) + 2d is no earlier than the time at which c; is proposed, since a 
report(c;) occurs prior to max(t, £time(a’)+e+d)+2d. Also, max(t, ftime(a’)+e+d)+ 
2d > ttime(a’)+e+2d. Therefore we conclude that members(c,) C J(max(t, Ctime(a’)+ 
e+d)+2d). This implies that 7 € J(max(t, 2time(a’) + e + d) + 2d). 

e i does not fail in 6(max(t, £time(a’) +e +d) +d): We know that i does not fail prior to 
event 7, that is, the recon(ci,c2); event. By Recon-Spacing-1, we know that time(z) > 
t+6d. By assumption of this case, we know that time() > £time(a’)+e+2d. Therefore 
i does not fail in B(max(t, 2time(a’) + e+ d) +d). 


We therefore conclude that cm is mainstream after max(t, /time(a’) + e + d) + 2d. 


We next apply Lemma 7.14, where t = max(t, £time(a’) +e +d) + 2d, t’ = max(t, ftime(a’) + 
e +d) + 6d, and cm is as defined above: 
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e e+2d< max(t, Ctime(a’) + e +d) + 2d: Immediate. 
e max(t, /time(a’) + e+ d) + 2d < max(t, ftime(a’) + e + d) + 6d — 2d: Immediate. 


e cm is mainstream after time(m): As shown above. 


Therefore, we conclude that cm is mainstream after max(t, £time(a’)+e+d) + 6d, as desired. 


We finally prove the main theorem, showing that read and write operations terminate rapidly. 
This result requires 12d+e-recon-spacing, and is similar to Theorem 8.17 from [13]. This earlier 
theorem states that in a normal, steady-state case, with good environmental behavior, read and 
write operations terminate within time 8d. Although the following theorem allows for more compli- 
cated behavior, deviating from the assumption of good environmental assumptions, read and write 
operations still complete rapidly. 


Theorem 7.29 Let a be ana’-normal execution satisfying: (1) (a,e)-join-connectivity, (ti) (a’, e)- 
recon-readiness, (iii) 12d+e-recon-spacing, (iv) (a’, e, 22d)-configuration-viability. 

Let t > ltime(a’) +e+17d, and assume a read or write operation starts at time t at some node 
i. Assume i € J(t+8d), and does not fail until the read or write operation completes. Also, assume 
that a@ contains decide events for infinitely many configurations. Then node i completes the read or 
write operation by time t + 8d. 


Proof. Let co,c1,c2,... denote the infinite sequence of successive configurations decided upon in 
a; by infinite reconfiguration, this sequence exists. For each k > 0, let 1, be the first recon(cp, Ch+1)« 
event in a, let iz be the location at which this occurs, and let ¢, be the corresponding, preced- 
ing report(c;,);, event. (The special case of this notation for k = 0 is consistent with our usage 
elsewhere. ) 

We show that the time for each phase of the read or write operation is < 4d — this will yield the 
bound we need. Consider one of the two phases, and let ~ be the read;, write; or query-fix; event 
that begins the phase. 

We claim that time(q) > time(do) + 8d, that is, that 7 occurs more than 8d time after the 
report(0);, event: We have that time(w) > t, and t > time(join-ack;) + 8d by assumption that 
a € J(t+ 8d). Also, time(join-ack;) > time(join-ack;,). Furthermore, time(join-ack;,) > time(¢o), 
that is, when join-ack;, occurs, report(0);, occurs with no time passage. Putting these inequalities 
together we see that time(wW) > time(do) + 8d. 

Fix k to be the largest number such that time(w) > time(¢z) + 8d. The claim in the preceding 
paragraph shows that such s exists. 

Next, we show that within zero time of ~ occurring, cmap(@); # L for all €< k. It is at this 
point that the proof diverges from that of Lemma 8.17 from [12]. 

For the purposes of the next two lemmas, fix any ¢< k. We apply Lemma 7.28, where @ is as 
fixed above, t = time(¢e), 6 = de, T = mm, C1 = ce,and 1 = ig. We therefore conclude that there 
exists a CMap cm such that: 


1. em(é) € L, and 
2. cm is mainstream after max(time(¢), £time(a’) + e + d) + 6d. 
We next apply Lemma 7.14, where t = max(time(¢y), 2time(a’) +e +d) + 6d, t' = time(a), and 


cm is as above, to show that cm is mainstream after time(q): 
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e e+ 2d < max(time(d,), Ctime(a’) + e +d) + 6d: Immediate. 


e max(time(¢,), Ctime(a’) +e + d) + 6d < time(y) — 2d: By the way in which k is chosen we 
know that time(¢,) + 8d < time(w). Also, time(¢e) < time(¢,): either 2 = k, or dg precedes 
me which precedes ¢,. By assumption we know that ftime(a’) +e+8d <t, and t < time(1)). 


e cm is mainstream after max(time(¢y), £time(a’) + e) + 6d: As shown above. 


Therefore, we conclude that cm is mainstream after time(w). We know that 7 € J(t), and t < 
time(w), so by Lemma 7.1, 7 € J(time(y)). Also, 4 does not fail until the read or write operation 
completes, and therefore either the read or write operation completes at time(7) (in which case we 
have proved the desired bound) or 7 does not fail in G(time(q)). Therefore by definition of a CMap 
being mainstream, if cm is mainstream after time(w), then cm < fstate(B(time(w))).cmap,. 

Having shown this for fixed £ < k, we now know that for all 2 < k there exists some CMap, 
cm, such that cm(@) # L and cm is mainstream after time(y), this implies that for all @ < k, 
éstate(B(time(w))).cmap(é); 4 L. Therefore we have shown that within zero time of ~ occurring, 
cmap(é); A L for all 2< k. 

Now, by choice of k, we know that time(q) < time(@x41) + 8d. The Recon-Spacing condition 
implies that time(m,41) (the first recon event that requests the creation of the (k + 2)" configura- 
tion) is > time(dz41) + 12d. Therefore, for an interval of time of length > 4d after 7, the largest 
index of any configuration that appears anywhere in the system is k+ 1. This implies that the 
phase of the read or write operation that starts with ~ completes with at most one additional delay 
(of 2d) for learning about a new configuration. This yields a total time of at most 4d for the phase, 
as claimed. 

Finally, by Corollary 7.27, the operation eventually terminates, which guarantees that ever 
configuration in op.cmap remains viable for long enough. 


This shows that assuming (a’, e, 22d)-configuration-viability is sufficient to guarantee that read 
and write operations terminate quickly. As long as the reconfiguration algorithm can guarantee 
this level of viability, the RAMBO IT algorithm will continue to make progress, regardless of any bad 
behavior the network may experience. Further, while 22d may seem a long period of time to ensure 
viability, it must be remembered that d is typically a small interval: we have been assuming that 
d is a single message delay in the network. Note that simply deciding on a new configuration to 
install might take many intervals of d (in [12], it is bounded by 11d). Also, this 22d bound is fairly 
conservative: by making stronger assumptions as to who begins configuration-upgrade operations, 
and how gossip messages propagate information about completed configuration-upgrade operations, 
it is probably possible to improve this bound. In this paper we are primarily interested in the fact 
that it is a constant time bound. 


8 Implementation and Preliminary Evaluation 


Musial and Shvartsman [16] have developed a prototype distributed implementation that incor- 
porates both the original RAMBO configuration management algorithm [12] and the new RAMBO 
II algorithm presented in this paper. The system was developed by manually translating the In- 
put/Output Automata specification to Java code. To mitigate the introduction of errors during 
translation, the implementers followed a set of precise rules, similar to [2], that guided the deriva- 
tion of Java code from Input/Output Automata notation. The system is undergoing refinement and 
tuning, however an initial evaluation of the performance of the two algorithms has been performed 
in a local-area setting. 
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Figure 21: Preliminary empirical evaluation of the average operation latency (measured as the 
number of gossip intervals), as a function of reconfiguration frequency, measured as number of 
reconfigurations per one reconfiguration period. 


The platform consists of a Beowulf cluster with 13 machines running Linux (Red Hat 7.1). 
The machines are Pentium processors in the range from 90 MHz to 900 MHz, interconnected via 
a 100 Mbps Ethernet switch. The implementation of the two algorithms shares most of the code 
and all low-level routines. Any difference in performance is traceable to the distinct configuration 
management discipline used by each algorithm. 

The machines vary significantly in speed. Given several very slow machines, Musial and Shvarts- 
man do not evaluate absolute performance and instead focus initially on comparing the two algo- 
rithms. 

The preliminary results in Figure 21 show the average latency of read/write operations as the 
frequency of reconfigurations grows from about two to twenty reconfigurations per one gossip pe- 
riod. In order to handle such frequent reconfigurations, a large gossip interval (8 seconds) is used. 
This interval is much larger than the round-trip message delay, thus reducing the effects of net- 
work congestion encountered when reconfiguring very frequently. The results show that the overall 
latency of read/write operations for the new algorithm progressively improve, as the frequency 
of reconfiguration increases. As expected, the decrease in latency becomes substantial for bursty 
reconfigurations (at 20 reconfigurations per gossip interval). For less frequent reconfigurations the 
latency is similar, at about 4 gossip intervals depending on the settings (not shown). This is ex- 
pected and consistent with our analysis, since the two algorithms are essentially identical when 
cmaps contain one or two configurations. Figure 22 shows the average number of configurations 
in cmaps as a function of reconfiguration frequency. This further explains the difference in perfor- 
mance, since the average number of configurations in cmaps is lower in the new algorithm as the 
frequency of reconfigurations increases. 

Finally notice that the modest number of machines used in this study favored the original algo- 
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Figure 22: Preliminary empirical evaluation of the average number of configurations in cmap’s, as 
a function of reconfiguration frequency, measured as number of reconfigurations per one reconfigu- 
ration period. 


rithm. This is because the machines are often members of multiple configurations, thus the number 
of messages needed to reach fixed-points by the read/write operations of the original algorithm is 
much lower than is expected when each processor is a member of a few configurations. 

Also, notice that this evaluation does not examine the effects of message loss and lack of network 
connectivity. We hypothesize that, as in the case of frequent bursty reconfiguration, when there 
are intervals of time in which the network is disconnected, the new algorithm should recover more 
rapidly. This testing has not yet been performed. 

Full performance evaluation is currently in progress. Shvartsman and Musial are investigating 
how the performance depends on the number of machines and various timing parameters. 


9 Conclusion and Open Problems 


In this paper we have presented a new algorithm, improving on the original RAMBO algorithm 
by Lynch and Shvartsman [12, 13]. While the original RAMBO algorithm is analyzed primarily in 
the context of good network behavior, we are able to show that our new algorithm functions well 
even when the network experiences transient periods of bad behavior, including message loss, clock 
skews, and arbitrary asynchrony, and when reconfiguration is bursty and uneven. 

The key to this improvement is a new rapid configuration-upgrade mechanism, which allows 
the system to stabilize rapidly after a period of bad network behavior. In the previous RAMBO 
algorithm, it might take arbitrarily long to recover from a period of bad behavior. In this new 
algorithm, however, within a constant time, the system returns to a steady-state condition. This 
allows the algorithm to function more reliably in a long-running, dynamic system: when a system 
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is expected to function for months and years without failure, it is necessary to rapidly recover from 
the inevitable transient network failures. 

This improvement also makes practical the design of algorithms to choose new configurations. 
In the earlier version of RAMBO, it is unclear what properties a reconfiguration algorithm must 
support in order for it to be useful. This paper shows that a reconfiguration automaton must 
provide exactly (a’, 22d)-configuration-viability. 

To design such a reconfiguration algorithm, then, is one of the major open problems posed by 
this paper. In particular, it seems important to show that if the rate of failure is bounded, then the 
algorithm continues to make progress. This is similar to the ideas introduced by Karger and Liben- 
Nowell in [10], in which they assume that the system has a bounded half-life: the time in which 
either half the processes fail or the number of active processes doubles. Under this assumption, 
they show that their algorithm operates correctly. 

By similarly assuming a bounded rate of failures, it should be possible in certain cases to design 
a reconfiguration algorithm that guarantees liveness by initiating reconfiguration with some min- 
imum frequency. By choosing appropriate quorums and appropriate numbers of reconfigurations, 
(a’, 22d)-configuration-viability should be possible. 

Other open problems include improving the join protocol, and designing a leave protocol to 
allow good detection of nodes that have exited the system. Currently, the join protocol is quite 
simple and it would seem beneficial to require more communication before allowing a node to 
initiate operations. And when nodes fail or leave, in the algorithm as stated, they are just ignored. 
By introducing a formal protocol to leave the system, and a method for detecting failed nodes, it 
might be possible to improve the long-run performance of the system. 

Another open problem is to determine how to recover when viability fails (and data is inevitably 
lost). More generally, is a self-stabilizing version of RAMBO feasible? It would also be interesting 
to determine whether a version of RAMBO could be adapted to tolerate Byzantine faults. 

RAMBO may also allow the construction of other data types, such as weakly consistent memory 
and sets. It may also be possible to optimize RAMBO to return read values more rapidly, in one 
phase, in certain cases. An important question would be to determine the most powerful data 
object that can be implemented using the RAMBO technique; one suspects that it is impossible to 
implement consensus in this manner. 

Finally, it would be interesting to examine how the RAMBO algorithm could be adapted to 
specific platforms. The algorithm is presented in a fairly abstract fashion. In real implementations, 
it would be optimized depending on the target platform. In particular, we suspect that RAMBO 
should work well in sensor networks, mobile-networks, and peer-to-peer networks. 

In conclusion, this paper has presented a new algorithm for atomic memory in a highly dynamic 
environment, proved that is always correct, and presented a set of conditions that guarantee liveness. 
This provides significant improvements over existing algorithms, rapidly recovering from transient 
network problems and bursty reconfiguration. 
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